Wo stehen wir in Sachen JavaScript und welche Entwicklung wäre wünschenswert?

Vorwort

Die folgenden Thesen mögen größtenteils schwarzmalerisch klingen. Doch es geht mir nicht darum, Pessimismus zu verbreiten. Im Gegenteil, es sind sehr erfreuliche Entwicklungen in der JavaScript-Welt zu verzeichnen – allerdings nicht ganz ohne Mankos.

Noch weniger geht es mir darum, mit meinen (freilich subjektiven) Einschätzungen über den Wissensstand weniger erfahrene JavaScript-Programmierer verächtlich zu machen oder irgendwem Unkenntnis vorzuwerfen. Im Gegenteil, diese Thesen über den gegenwärtigen Status sollen ungeklärte Fragen und Herausforderungen aufzeigen. Wo stehen wir und welche Entwicklung wäre wünschenswert? Mit welchen Fragen sollten wir uns stärker beschäftigen? Was kann dazu beitragen, das Wissen über JavaScript zu erweitern und zu verbreiten?

Nicht zuletzt könnten die Thesen als eine Aufgabenliste für uns bei SELFHTML dienen. Schließlich gilt es, die fraglichen Themenbereiche mit technischer Dokumentation zu beackern und zu ihrer Aufklärung beizutragen.

1. JavaScript als Technik explodiert

Die Browser rüsten hinsichtlich ihrer JavaScript-Interpreter auf. JavaScript/ECMAScript wird Scriptsprache auf immer mehr Plattformen. Die Performance rückt in den Vordergrund, sodass bald komplexere Operationen möglich sind. Mit Google Gears bzw. Google Chrome (JavaScript-Engine »V8«) und Firefox 3.1 (JavaScript-Engine TraceMonkey«) entstehen JavaScript-Interpreter, die z.B. durch Hintergrundprozesse (1, 2, 3) um ein vielfaches leistungsfähiger werden.

Gleichzeitig arbeiten Browserhersteller und Industriegrößen an einem zukünftigen ECMAScript-Standard. Auch wenn bisher Uneinigkeit herrschte, so hat man sich nun auf ECMAScript 3.1 und das darauf folgende ECMAScript »Harmony« geeinigt.

Die Schnittstellen, die mit JavaScript angesprochen werden können, nehmen zu. HTML 5 macht Platz für Canvas, Web Forms, Audio und Video, Drag and Drop, DOM Storage, Cross-Document Messaging und vieles mehr. Kommende Browser unterstützen SVG-Einbettung, Cross-Site XMLHttpRequest, JSON sowie die Selectors-API. Der Acid3-Test demonstriert viele dieser Techniken.

Den Überblick verloren oder kein Wort verstanden? Genau das droht: Das bisher (vergleichsweise) recht überschaubare JavaScript mit ein bisschen DOM-Scripting und Ajax ufert in seinen Möglichkeiten und Anwendungsbereichen aus.

Die Browserhersteller liefern sich Wettbewerbe um Performance und Unterstützung neuer Techniken, dabei kann bisher kein durchschnittlicher JavaScript-Programmierer sagen, was mit den neuen Standards eines Browsers, der z.B. den Acid-3-Test besteht, anzufangen ist – bei aller Medienberichterstattung wurde diese Kernfrage unterschlagen.

Bis die neuen Möglichkeiten sauber implementiert, in Beispielanwendungen demonstriert und vor allem für Normalsterbliche dokumentiert werden, werden wahrscheinlich noch einige Jahre vergehen.

2. Basale Programmiertechniken finden (keine) Verbreitung

Nachdem es einflussreiche Stellen seit Jahren predigen, finden einfache Techniken zur Organisation von JavaScripten anscheinend endlich Anklang: Das Object-Literal und einfache objektorientierte Programmierung mithilfe von Konstruktor-Funktionen, Eigenschaften und Methoden.

Dies führt immer mehr Javascript-Anwender zu der Frage, wie man beim Event-Handling und bei der Verwendung von setTimeout/setInterval Zugriff auf das Instanzobjekt hat, denn this zeigt in diesen Fällen auf das falsche Objekt. Ausgehend von solchen Fragestellungen werden auch schwierige JavaScript-Raffinessen wie Closures immer bekannter.

Neben dieser erfreulichen Beobachtung ist auf einer Ebene darunter eher Gegenteiliges festzustellen: Grundlagen wie Cross-Browser-Event-Handling sind schlicht unbekannt. Damit meine ich etwa das Schema zum traditionellen Registrieren von Event-Handlern (element.onevent = handlerfunktion;), den browserübergreifenden Zugriff auf das Event-Objekt, Kenntnis des Bubbling-Effektes usw.

Dabei ist das genannte Schema im Grunde längst veraltet – außerhalb von Bibliotheken haben es fortgeschrittene addEvent-Helferfunktionen nicht in den Alltag der Webentwickler geschafft. Hier mangelt es schlichtweg massiv an (zumal deutschsprachigen) Dokumentationen, die diese Grundlagen nicht nur anwenden, sondern herunterbrechen und verständlich erklären.

3. Die JavaScript-Anwendung wird breiter, nicht unbedingt gezielter

Nachdem JavaScript wieder geachtet ist und viele von JavaScript-Webanwendungen beeindruckt sind, werden mehr und mehr Wünsche an JavaScript herangetragen. Diese erfüllen JavaScript-Profis meist hilfsbereit. Auch auf die Gefahr hin, dass dieses Mantra oberlehrerhaft klingt: Nicht alles, was mit JavaScript gelöst werden kann, ist überhaupt eine sinnvolle Aufgabe für JavaScript.

JavaScript ist trotz ständig wachsender Möglichkeiten keine frei schwebende, universell einsetzbare Technik, sondern steht im Kontext mit anderen Webtechniken. Das ist erster Linie der möglichst harmonische Dreiklang HTML – CSS – JavaScript und das Ineinandergreifen von clientseitiger und serverseitiger Technik. JavaScript hat eigentümliche Fähigkeiten und ihm kommen im besagten Zusammenhang bestimmte Aufgaben zu.

Sich mit JavaScript auszukennen, sollte in erster Linie heißen, den möglichen und sinnvollen Anwendungsbereich einschätzen zu können. Wie selbstverständlich werden heute Probleme mit JavaScript zu lösen versucht, für die JavaScript nur schlecht geeignet ist und für die z.B. serverseitige Lösungen geeigneter wären.

JavaScript-Einsteiger sollten das Schreiben von »konventionellen« Webseiten gemäß den Webstandards beherrschen und um deren Vorteile wissen. Zudem sollten sie die Funktionsweise des Webs verstehen, um zu einer optimalen Zusammenarbeit zwischen Client- und Servertechniken zu kommen. Dieses grundlegende Handwerkszeug ist nämlich vonnöten, um zu verstehen, was man mit JavaScript-Webanwendungen gewinnt und was man gegebenenfalls verliert.

4. Ajax-Revolution wurde nicht reflektiert

Dass JavaScript extensiv dazu verwendet wird, um Inhalte im Hintergrund vom Server nachzuladen, hat Auswirkungen auf Benutzbarkeit und Zugänglichkeit, die größtenteils unerforscht oder unbewusst sind.

Zwar gab es während des Ajax-Hypes vor ein paar Jahren eine Diskussion in der internationalen Blogosphäre darüber, wie diese neue Technik das Web auf den Kopf stellt und wann ihr Einsatz angebracht bzw. deplatziert ist. Aber die breite Basis der Ajax-Entwickler hat diese Diskussion nicht erreicht. Eine griffige Sinnstiftung von Ajax, auf die man sich einigen könnte, wurde noch nicht hervorgebracht – die Diskussion geht natürlich weiter.

XMLHttpRequest ersetzt z.B. Techniken wie (I)Frames, während über die Nachteile und die Bedingungen eines robusten Einsatzes nicht nachgedacht wird. Anstatt das überflüssige Herunterladen neuer Dokumente vom Server zu vermeiden, gefährdet Ajax in diesen Fällen bloß das bewährte Modell des adressierbaren Dokuments, dessen Inhalte vernünftig ausgezeichnet sind.

Auch hinsichtlich Ajax und Accessibility mangelt es an Grundlagenforschung. Aussichtsreiche Techniken wie WAI-ARIA (siehe etwa Barrierefreie Web-2.0-Anwendungen mit WAI ARIA und
Introduction to WAI ARIA) sind außerhalb von Expertenzirkeln noch unbekannt.

5. »Unobtrusive JavaScript« bleibt eine Nische

Das Konzept des Unobtrusive JavaScript (siehe auch The seven rules of Unobtrusive JavaScript) sollte einst aus dem dunklen Tal von »DHTML« und allgegenwärtigem JavaScript-Missbrauch zur aufgeklärten JavaScript-Verwendung führen. Bisher ist Unobtrusive JavaScript mit seiner fortschreitenden Verbesserung die stimmigste Theorie.

Zwar fußen zunehmend Fertigscripte und Bibliotheken darauf, aber sie gehört noch lange nicht zum Allgemeinwissen. Unobtrusive JavaScript erfordert eine strikte Trennung von HTML und JavaScript. Damit
kommt dem dynamischen Event-Handling eine enorme Wichtigkeit zu. Leider scheint sich das Wissen über einfache onload-Techniken und fortgeschrittene wie »DOMContentLoaded«, mit dem Scripte dem Dokument automatisch Interaktivität verpassen können, viel zu wenig herumgesprochen zu haben.

Zum Teil ist sogar ein »Backlash« zu beobachten: JavaScript-Unterstützung, der alleskönnende Browser und der ideale Benutzer werden stillschweigend vorausgesetzt. Die bewährten Mechanismen, die Zugänglichkeit und Bedienbarkeit von Webseiten garantieren, greifen nicht mehr. Nur selten ist eine Umsetzung, die JavaScript-Unterstützung zwingend benötigt, wirklich vorteilhaft und geboten. Kompatible und zugängliche Lösungswege werden zu wenig bedacht.

6. Bibliotheken tragen bisher wenig dazu bei, das Know-How über JavaScript-Programmierung zu verbessern

Oft werden Bibliotheken so gehandelt, als würden sie das Schreiben von JavaScript ohne JavaScript-Kenntnisse ermöglichen. Gleichzeitig ist es erschreckend, wie wenig Dokumentation (nicht trockene API-Referenzen), Tutorials und Beispiele mitgeliefert werden. Wenn Einsteiger mit Bibliotheken alleine gelassen werden, kommt langfristig wenig heraus.

Bibliotheken nivellieren Browserunterschiede und bieten Helferfunktionen an, die Webautoren viel Arbeit abnehmen. Sie nehmen einem nicht das Verständnis von Grundlagen ab, sondern setzen diese stillschweigend voraus. Die Praxis zeigt, dass Anwender früher oder später durch das Netz der Bibliothek fallen. Ohne die nötigen Grundlagen fällt es dann schwer, auf sich alleine gestellt weiterzukommen. Die wünschenswerte »Ermächtigung« der Webautoren durch Bibliotheken ist daher nur dann möglich, wenn sie angemessen informiert und ausgebildet werden.

In verschiedenen Umfelden habe ich die Erfahrung gemacht, dass eine Nutzung von Bibliotheken immer wieder darauf hinausläuft, dass in den Code der Bibliothek geschaut werden muss, um deren Verhalten und Funktionsweise zu erklären. Das liegt einerseits am Phänomen der leaky abstraction, andererseits an unzureichender Dokumentation. Das Nachvollziehen des anspruchsvollen Codes wiederum ist nur einem kleinen Spezialistenkreis möglich.

7. Möglichkeiten von Bibliotheken bleiben ungenutzt

Helferscripte und Bibliotheken bewegen sich zunehmend auf hohem Niveau und geben – eine gute Dokumentation vorausgesetzt – gute Beispiele ab. Sie könnten das Know-How über JavaScript-Programmierung (siehe voriger Punkt) also durchaus verbessern: Bibliotheken betonen vernachlässigte Features wie die funktionalen Programmierung und bringen Programmierstile aus anderen Sprachen in die JavaScript-Welt. Beispielsweise erweitert Prototype die bestehenden Kernobjekte auf breiter Ebene, bietet darüber hinaus abstrakte Typen wie Enumerable und Hash. Schließlich hilft die Bibliothek bei dem Entwerfen eigener »Klassen«.

Diese Innovationen haben die meisten Nutzer der Bibliotheken noch nicht erreicht. Diese stehen vor der Bibliothek wie der Ochs vorm Berg, sodass sie gerade einmal drei, vier Funktionen nutzen. Diese Problematik habe ich bereits in einem früheren Artikel beschrieben. Bis dato halte ich Skepsis gegenüber riesigen Allround-Bibliothek Bibliotheken, von denen 5% genutzt und 1% verstanden werden, für angebracht.

Mit verschiedenen Bibliotheken ist ein hochentwickelter Programmierstil möglich. In der Praxis habe ich noch nahezu kein Script gesehen, das schwerfälligen »Spaghetti-Code« und Low-Level-OOP vermeidet zugunsten der Vereinfachungen und Abstraktionen, die die verwendete Bibliothek anbietet.

Das ist kein Vorwurf oder eine Aufforderung, die Vorgaben der Bibliothek auswendig zu lernen. – Ich selbst bin der Letzte, der deren Abstraktionsfähigkeiten im Kopf hat, und halte das auch nur bedingt für erstrebenswert. – Es soll bloß unterstreichen, dass Programmierer diejenigen Techniken anwenden, die sie verstehen und beherrschen. Vielen unterstützenswerten Konzepten ist es leider noch nicht gelungen, die Programmierer zu erreichen.