Ergänzung zur Frage, ob JavaScript-Frameworks eine Sonderrolle einnehmen

Ad Stefan:

Ich bin ja kein Programmierer und kenne auch nicht viele Sprachen en detail, habe aber das Gefühl, dass JavaScript eine Sonderrolle im Hinblick auf Bibliotheken und Frameworks einnimmt. Beziehungsweise Frameworks in JavaScript erfüllen grundlegendere Aufgaben, deren Abstraktionsleistung ist eine andere.

Die meisten Web-Programmiersprachen bringen die wichtigsten Funktionen schon mit und es gibt einen relativ festen Rahmen. Dieser entwickelt sich weiter, aber relativ zentralisiert. Außerdem gibts nur einen relevanten Interpreter oder sie gleichen sich ziemlich. Zudem gibt eine festgelegte Struktur für interne Modularisierung und externe Erweiterbarkeit, sprich PEAR und Co. Man kann problemlos abgeleitete Klassen schreiben und so weiter, sodass man das Rad nicht neu erfinden muss.

In JavaScript ist das Angebot dürftig, da gibts erstmal verschiedene APIs verschiedener Herkunft, den Flickenteppich habe ich schon beschrieben. Eine Weiterentwicklung findet nicht statt oder halt dezentral bei den Browserherstellern (selbst wenn die die Standards nicht selbst entwickeln - sie implementieren sie letztlich unabhängig voneinander). Ein vordefiniertes System für Erweiterungen gibts nicht, stattdessen dominiert Wildwuchs. Selbst der Sprachkern ist unterschiedlich implementiert und es gibt proprietäre Erweiterungen. Die Erweiterung von Klassen (Prototypen) funktioniert nicht browserübergreifend. So muss ich letztlich unterschiedliche Scripte für die unterschiedlichen Interpreter und deren Features schreiben.

In der krassen Weise findet man eine solche zersplitterte und zerfaserte Situation m.W. nur bei JavaScript. Das räumt JavaScript-Frameworks einen besonderen Stellenwert und eine besondere Brisanz ein, weil es im Gegensatz zu anderen Sprachen für Standardaufgaben kein verlässliches Fundament gibt (man denke an so Basics wie Event-Handling!).

Was natürlich möglich ist, ist der Rückzug auf (bestehende und kommende) Standards und die Angleichung aller Browser auf dieses Niveau durch eine JavaScript-Bibliothek, die Implementierungslücken ergänzt. Den Ansatz verfolgt Dean Edwards mit base2.dom. Das Level, was damit hergestellt wird, würde ich mit dem anderer Programmiersprachen ohne Benutzung eines Frameworks vergleichen. Erst auf einer solchen Basis könnten sich Frameworks ausdifferenzieren, die sich auf verschiedene Programmierparadigmen ausrichten.

jQuery z.B. macht letzteres auch, gerade das unterscheidet solche Bibliotheken von bloßen »DHTML-Bibliotheken«, die es schon immer gab. Insofern werden Frameworks als solche in JavaScript erst gerade entdeckt. Trotzdem haben sie einen großen Fokus darauf, die Browserdifferenzen einzuebnen und den Umgang mit dem DOM zu vereinfachen. Das ist m.E. ein Grund, warum Kauderwelsch-Code so verbreitet ist.

Meine These ist halt, dass die Notwendigkeit der Abstraktion … beim gegenwärtigen, lückenhaften und unausgereiften ECMAScript und DOM quasi genetisch veranlagt ist. Das würde ich bei anderen Sprachen nicht behaupten, weil sie von Haus aus eine stabilere Umgebung zur Verfügung stellen.

Die Entwicklung und Implementierung von Standards im Bereich JavaScript/DOM sehe ich in den Kinderschuhen, sodass ich die jetzigen Frameworks als eine Art Krisen- oder Übergangsphänomen werte. So gesehen lösen sie zum großen Teil Probleme an einer Stelle, die eigentlich nicht durch ein Framework, sondern die API bzw. Sprache gelöst werden sollten, wie es bei anderen Sprachen auch getan wird. Wenn in allen Browsern entsprechende Techniken nativ implementiert wären, wäre die Situation womöglich eine ganz andere. Dahin geht auch der Trend (HTML 5, neue DOM-Standards, ECMAScript Edition 4, Mozillas JavaScript-Extensions...), aber ziemlich langsam.