Wie Bibliotheken neue Voraussetzungen für das Vermitteln von JavaScript schaffen

Ungeklärte Umbrüche

Was viele Webworker betrifft und beschäftigt, sind die in den letzten Jahren aus dem Boden geschossenen JavaScript-Frameworks wie Prototype, jQuery, Dojo und sonstige Ajax-, Interface- und Effektbibliotheken. Dieser Umbruch scheint mir in seinen Hintergründen noch nicht geklärt und die Auswirkungen noch nicht abschließend aufgearbeitet zu sein – vor allem im Hinblick auf die technische Dokumentation und Vermittlung von JavaScript: Diese neue Situation beschäftigt mich bei der Arbeit an einer kleinen Einführung in JavaScript, da sie Fragen aufwirft wie »Soll man noch JavaScript lernen oder gleich jQuery?« und »Wie hängt der Einsatz von Frameworks mit dem Lernen von JavaScript zusammen?«

Bibliotheken in der kritischen Diskussion

Die Diskussion um die Vor- und Nachteile von JavaScript-Bibliotheken lief Ende letzten Jahres groß in der internationalen Blogosphäre. Auf der @media-Konferenz 2006 fand eine Podiumsdiskussion zum Thema Javascript Libraries: Friend or Foe? statt, die als MP3-Mitschnitt und Transkript vorliegt. Eine Übersicht über die Diskussion in Weblog-Artikeln bietet Peter-Paul Koch. Ich möchte ihr nichts substanzielles hinzufügen, sondern ein paar subjektive Notizen, lose Ideen und Beobachtungen in Sachen JavaScript-Geschichtsschreibung zusammentragen.

JavaScript ist wieder cool – Gründe und Folgen

Wenige JavaScript-Spezialisten wie etwa die, die auf der @media-Veranstaltung diskutierten, versuchen schon seit langem, JavaScript ein positives Image zu geben und vernünftigen Gebrauch zu propagieren. Als DOM Scripting und Unobtrusive JavaScript gelang das auch im begrenzen Maße, aber wirklich ausschlaggebend für den neuerlichen Run auf JavaScript waren Ajax, die Effekte sowie der einfache Einsatz von JavaScript an sich durch Bibliotheken. Dadurch gewann JavaScript Interessenten, die mit anderen Erfahrungen und Zielen an JavaScript herantraten. Eine spannende, aber auch herausfordernde Entwicklung für diejenigen Enthusiasten, die JavaScript-Techniken und -Theorien weiterentwickeln.

Durch kinderleichte Werkzeuge wie jQuery hat JavaScript eine starke Popularisierung erlangt – viele können JavaScript einsetzen, ohne JavaScript können zu müssen. Frameworks verwirklichen den Grundsatz: »The bad news: JavaScript is broken. The good news: It can be fixed with more JavaScript.« Sie vereinheitlichen den Flickenteppich von APIs unterschiedlicher Herkunft und Machart. Sie setzen Programmiertechniken voraus, die dem gemeinen JavaScript-Programmierer vorher meist unbekannt waren.

Die Entwicklung von Bibliotheken selbst nachvollziehen

Dieser vorgegebene Rahmen kann zu guten Resultaten verhelfen, Voraussetzung ist allerdings, dass der Anwender um die Vorteile und Hintergründe dieser Programmierweise wissen. Den Prozess vom Spaghetticode zum Framework – von der Erfindung von Helferfunktionen wie getElementsByClassName bis hin zu $("beliebige CSS- oder XPath-Selektoren").chainability() – lief über viele Jahre. Diese Entwicklung nachzuvollziehen wäre zum Verständnis aktueller Ansätze nötig, ist den meisten aber nicht ohne weiteres möglich, da sie nie selbst Helferfunktionen entwickelt haben, die den vorherigen Programmierstil grundlegend über den Haufen warfen.

Obgleich gibt es dutzende Helferscripte, die Schritt für Schritt optimierten Code für häufige Aufgaben ermöglichen, man denke alleine an die Veränderungen, die eine Helferfunktion wie forEach bereits mit sich bringt. Die Notwendigkeit der Abstraktion ist beim gegenwärtigen, lückenhaften und unausgereiften ECMAScript und DOM quasi genetisch veranlagt – man muss sich nur überlegen, wie man am besten hineinkommt.

Unzugängliche und monolithische Fertigbibliotheken

Die Interna von Frameworks sind für die meisten undurchschaubare Rocket Science, ihr Code unlesbar, ihre Funktionsweise unklar, ihre Dokumentation nicht für Einsteiger geeignet. Hinter den Designentscheidungen stecken Jahre Forschung und Fachdiskussion. Heraus kommt, dass die Bibliothek auf Außenstehende nicht wie ein Baukasten, sondern wie ein monolithisches Ganzes, wie eine Black Box wirkt. Wenn sie dann noch nichtmal im Ansatz modularisierbar ist und der Anwender keinen Schimmer davon hat, welche Teile welche Funktion erfüllen und ob diese benötigt werden, heißt es leider Fressen oder Sterben. Wenn man hinter die Kulissen der API schaut, findet man ohnehin selten aufgeräumten Code, der auf Allgemeinverständlichkeit und Anpassbarkeit angelegt ist.

Ein großes Problem der Bibliotheken-Benutzung scheint mir, dass sie nicht benutzt werden: Von hunderten Features, die eine Bibliothek bietet, bleiben die meisten unbekannt. Ein paar wenige zentrale Features werden extrem häufig verwendet, die Mehrheit liegt außerhalb dieses Kreises. Schuld daran sind fehlende Tutorials und nutzlose API-Referenzen, aber auch ein falsches Verständnis von Bibliotheken als eierlegende Wollmilchsäue, Allround-Werkzeuge selbst für den unmöglichsten Fall – sie sind schlicht und einfach bloated anstatt auf das Wesentliche reduziert.

Kauderwelsch aus JavaScript und Bibliotheken

Damit einher gehen Scripte, bei denen Framework-Logik und konventionelles JavaScript vermischt werden. Rudimentäre Kenntnisse der herkömmlichen Lösungsweise vermischen sich mit rudimentären Kenntnissen des Frameworks. So kommt Code heraus, der in einer Zeile die Bibliothek nutzt und in der nächsten wieder völlig an ihr vorbeiprogrammiert. Das Kauderwelsch, das immer wieder aus der Logik des verwendeten Frameworks herausfällt und dieses überhaupt nicht ausreizt, ist inkompatibel, schwer verständlich und scheußlich wartbar.

Bei kleinen, begrenzten Helferbibliotheken (man denke an DOMAssistant, ff oder Dan Webbs Scripting Essentials) wäre dies kein großes Problem, aber es entspricht nicht dem Totalitätsanspruch derjenigen Biliotheken, die einen einheitlichen Abstraktionslayer ohne Schlupflöcher zur Verfügung stellen wollen.

Zwischen Entwicklern von Bibliotheken-Plugins sowie Fertigscripten und den JavaScript-Theoretikern scheint eine Kluft zu verlaufen. Diese drückt sich darin aus, dass deren Standardwerke oftmals nicht rezipiert wurden und beispielsweise manche populären Scripte wie Thickbox jegliche Organisation vermissen lassen. Das ist coding like 1998, nur mit jQuery im Nacken. Viele solcher Erweiterungen fallen systematisch aus der Logik des Frameworks heraus und nutzen von der 77-Kilobyte-Bibliothek nur zwei gesonderte Funktionen – dieses ein »Plugin« zu nennen, ist eine Dreistigkeit, aber durchaus an der Tagesordnung.

Die Herausforderung neuer Einstiege in die JavaScript-Entwicklung

Wie soll diese Chose nun JavaScript-Anfängern nahegebracht werden? Seitdem es jQuery und Co. gibt, lautet die Antwort auf unzählige Anfängerfragen: Macht dir keinen Kopf und nimm gleich jQuery (oder ähnliches). Der Erfolg ist garantiert, ein tieferes Verständnis von JavaScript nicht. Dementsprechend rächt es sich, Aufgaben gar nicht zu durchdenken, sondern alle Hoffnungen in ein Framework zu setzen.

Aktuelle JavaScript-Bücher erklären die Benutzung von Frameworks erst am Ende und führen vorher höchstens kleine Helferfunktionen ein (z.B. DOMhelp.js aus dem Buch Beginning JavaScript von Christian Heilmann). Das tun sie mit Recht – den tatsächlichen Entwicklungen entspricht aber eher das Gegenteil: Die Leute werden durch die Frameworks zu JavaScript gebracht, nicht umgekehrt. Deren Popularität liegt gerade darin, dass sie JavaScript zum convenience food, zum Fertiggericht machen. Diesem Umstand wurde bei der Vermittlung von JavaScript m.E. bisher noch nicht Rechnung getragen.

Was kann und soll ein JavaScript-Tutorial leisten?

Viele meiner Anmerkungen klingen so, als würde ich mich gegen die jüngsten Umbrüche im JavaScript-Geschäft aussprechen. Dem ist nicht so. Durch die Verwerfungen liegt aber viel Arbeit vor uns, vor allem im Hinblick auf das Dokumentieren, Vermitteln und Lehren von JavaScript.

Einerseits sehe ich es nicht als die Aufgabe von SELFHTML an, Menschen die sinnvolle und korrekte Verwendung bestimmter Frameworks nahezulegen, die ihrerseits das Rad auf unterschiedliche Weise neu erfinden. Diese Aufgabe sollte deren Dokumentation erfüllen, schafft es aber nur selten. Andererseits gehört es zum notwendigen JavaScript-Grundwissen, Bibliotheken und Frameworks im Allgemeinen selbstbestimmt einsetzen (und bestenfalls selbst entwickeln) zu können und dabei jederzeit zu wissen, was man tut. Dem machen wiederum die gegenwärtig populären Monsterbibliotheken einen Strich durch die Rechnung.

Letztlich muss ein JavaScript-Tutorial, dass sich nicht gleich der völligen Abstraktion hingibt, auf die Unzulänglichkeiten der bestehenden APIs hinweisen, wiederkehrende Muster aufzeigen und Ansätze erklären, wie umständliche Wege durch Abstraktion vereinfacht werden können. Dafür erscheinen mir die besagten Minimal-Bibliotheken DOMHelp, DOMAssistant, forEach und ähnliche Ansätze gut geeignet zum Einstieg. Davon zu unterscheiden sind abgeschlossene Frameworks, die quasi eigene Meta-Sprachen einführen und sich vor der schrittweisen Vermittlung bisher sperren.