Sieben Thesen zum gegenwärtigen JavaScript-Gebrauch

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.

4 Kommentare » Schreibe einen Kommentar

  1. Eine sehr gute und breite Betrachtung des Themas, danke!

    Für Firmenwebsites immer wieder schwierig ist aus meiner Sicht die Frage der Berücksichtigung der Nutzer ohne Javascript.

    Sollte man diese berücksichtigen, obwohl es nur 3% sind (bei uns jedenfalls)?
    Oder, gehört es zum guten Ton und auch zur Barrierefreiheit, hierfür gesonderte Inhalte (mit gesondertem Aufwand!) anzubieten?

    Grüße

    F. Witter

  2. Hallo Mathias!

    Du schneidest so viele unterschiedliche Aspekte in deinem Artikel an, dass man kaum zu allen Dingen Stellung nehmen kann, bzw. seine Meinung äußern kann, ohne dabei den Umfang eines kompletten Buches zu erreichen.

    Deshalb möchte ich hier nur mal auf die meiner Meinung nach "Wurzel allen Übels" eingehen.

    Diese sehe ich in aller erster Linie darin begründet, dass sämtliche "Webtechniken" in ihrer Weiterentwicklung alle ausnahmslos auch immer komplizierter werden!

    Vom "KISS-Prinzip" (keep it stupid simple) keine Spur!

    Aber war es nicht gerade diese Einfachheit, die es nahezu Jedermann in den Anfangszeiten des Internets ermöglichten, auch leicht eigene Inhalte im Web zu publizieren, die maßgeblich zum Erfolg des Internets beigetragen haben?

    Mittlerweile "verkommen" immer mehr Bereiche der zugrundeliegenden Techniken zur "Spielwiese" von irgendwelchen Spezialisten – leider scheinen es auch nur noch diese zu sein, die die jeweiligen Weiterentwicklungen bestimmen.

    Auch die von dir angesprochenen (und nicht gemochten) Frameworks sind für mich der typische Beweis dafür, dass die zugrundeliegende Technik zu "kompliziert" (geworden) ist.

    Wenn ich mir beispielsweise mal PHP und Javascript angucke und die Zahl der existierenden/ verwendeten Frameworks, dann wird der Unterschied wohl schon recht deutlich.

    Ein weiteres Problem sehe ich auch darin, dass sich Weiterentwicklungen leider auch nicht immer an den Wünschen, Erfordernissen und Anforderungen der Anwender orientieren, sondern teilweise auf einer für den geübten Laien kaum mehr nachvollziehbaren "Ebene" stattfinden. Das Ergebnis ist dann oft für Nicht-Spezialisten so gut wie kaum verständlich, da jeglicher "intuitiver" Zugang nahezu unmöglich ist. Bestes Beispiel hierfür ist imho CSS. Nach zig Jahren und im vierten Anlauf (CSS 3) bemüht man sich jetzt so "profane" Dinge wie bspw. calc einzubauen – eine Sache, die viele Webautoren schon seit Jahren hätten gut gebrauchen können und sicherlich auch leicht verstanden hätten.

    Und solcherlei Beispiele gibt es noch etliche mehr.

    Es verwundert mich kein bischen, dass der von dir angeprangerte Verlust des "Basiswissens" bei immer mehr Webautoren um sich greift. Wenn zum einen immer mehr und neue Techniken dazukommen, und zum anderen diese, als auch die bereits vorhandenen immer komplizierter werden, dann wird imho die Gruppe derer, die das noch alles in vollem Umfang überblickt und beherrscht immer kleiner! Ein umgekehrt proportionales Verhältnis.

    Frameworks schaffen hier eine gewisse Abhilfe. Sei es, dass ich z.B. deren Syntax aufgrund von Kenntnissen in anderen (Script-/ Auszeichnungs-)Sprachen leichter und schneller beherrsche, als die der eigentlichen Grundtechnik und so schneller an mein angestrebtes Ziel komme. Natürlich bringen Frameworks auch eine Menge Nachteile mit sich, von denen du ja bereits schon einige aufgezählt hast. Wie eingangs bereits erwähnt, halte ich sie nicht für eine Lösung oder echte Alternative. Ich sehe in ihnen vielmehr den Beleg/ Beweis dafür, dass sich ihre zugrundeliegende Technik zu kompliziert und somit praxisfern gestaltet. Und genau daran sollte man arbeiten, und nicht an einer besseren Dokumentation der zahlreichen und untereinander verschiedenen Frameworks!

    Denn die parallele existenz mehrerer verschiedener Frameworks zu ein und derselben Sprache verschlimmert das Dilemma (für den Webautor) ja noch zusätzlich.

    Ich hoffe, mein Standpunkt ist deutlich geworden? Ich stimme dir und deinen Thesen ja weitestgehend zu, nur sehe ich (vermutlich) die (Haupt-)Ursache dafür eben woanders.

    Gruß
    Gunther

  3. Ich bin ja nun kein JavaScript-Schreiber und schon gar kein Spezialist zu dem Thema. Sehr wohl aber kenne ich die ganzen Problematiken darum herum und vor allem in Bezug auf Accessibility.

    Vor ein paar Tagen hatte ich darüber etwas allgemeiner geschrieben: Javascript – der Spaß hat Grenzen.

    Danke für diesen hervorragenden Wo stehen wir eigentlich-Beitrag, der die Sache nüchtern aus technischer Sicht anspricht.

    Du sprichst auch eine Sache an, die nämlich wirklich akut ist: oft mangelnde Dokumentationen mit Beispielen.

    Ich persönlich würde es sehr begrüßen, wenn SELFHTML dieses Thema ausführlicher beackern könnte. Ich glaube, dafür würde breiter Bedarf vorhanden sein!

  4. Danke für den Beitrag. Ich glaube (nun noch viel mehr), dass Internetseiten konsequenter in mindestens zwei Kategorien eingeteilt und behandelt werden müssten:

    1. Seiten zum Informationsaustausch (Eindeutig adressiert, WAI, wenig bis kein JavaScript)

    2. Anwendungen (Alles, was der Browser hergibt und für 1. so viel Probleme bereitet)

    Das sind zwei völlig unterschiedliche Disziplinen! Ich habe den Eindruck, dass immer wieder versucht wird, eine einzige Auffassung von dem, wie eine Seite aussehen muss, zu halten.

    Ich wäre sogar für eine Pflichtangabe in jeder HTML-Datei, die die Seite eindeutig in eine Kategorie einordnet. So ließen sich Seiten der Kategorie 1 (nur) in einem klassischen Browser öffnen und Seiten der Kategorie 2 (nur) in speziellen Browsern / Browserfenstern (wie Prism oder dem Anwendungsfenster von Chrome).

    Viele andere Problematiken wie "der richtige Umgang mit den neuen Techniken" wären damit wahrscheinlich schon gelöst, weil ja schließlich jeder das Recht hat, schlechte Anwendungen zu schreiben, ohne dass zum Beispiel der Anspruch der Barrierefreiheit besteht oder der, dass die Seite in allen aktuellen Browsern funktioniert.