A Programmer's Blog

Rest in peace Flex … oder: was ich in der Javascript-Welt vermisse …

Apr
21

Seit ich HTML und Javascript entwickele, wächst in mir eine Trauer. Ich trauere um Flex und ich trauere um Actionscript. Ich trauere um eine Art der RIA-Entwicklung, wie sie sein sollte. Actionscript und vor allem das Flex-Framework boten so vieles, was ich in der Javascript-Welt einfach nicht wiederfinde.

Im Folgenden werde ich auf einige Dinge eingehen, die mir ganz besonders fehlen. Für Lösungsvorschläge bin ich natürlich sehr dankbar!

Vollständige, flexible und stylebare UI-Komponenten

Hier hatte ich nie mit Problemen gerechnet. Für mich war beim Wechsel ganz klar, das es da draussen UI-Bibliotheken geben müsse, die zumindest annähernd so vollständig und flexibel sind, wie die von Flex … Aber Pustekuchen!

jQueryUI, YUI und wie sie alle heissen, sie alle bieten nur eine unvollständige Anzahl an zusammengewürfelten Komponenten, die wenig mit einemv ollständigen Baukasten für eine RIA zu tun haben. Zudem haben sie meist kein einheitliches Konzept von Erweiterbarkeit oder Wiederverwendbarkeit. Und noch dazu ist das Styling in CSS meist die Hölle. Mein Lieblingsbeispiel ist hier das Menu von YUI-3 : Schwierig zu stylen, so gut wie nicht konfigurierbar, es gibt überhaupt keine Events und beim Initialisieren der Seite zickt und zuckt es das ich Augenkrebs bekomme. Und das ist die Zukunft?

Wer mir ein open-source UI-Framework nennen kann, das so vollständig, so einfach zu verwenden, zu stylen und trotzdem so anpassbar wie Flex ist, dem werd ich persönlich die Füße küssen!

Data-Binding

In Flex ist das Entwickeln von Views einfach genial. Mittels Data-Binding werden Daten des Models gebunden und damit ist das View-Verhalten ganz klar vom Controller-Code getrennt. Und wie ist das mit jQuery? Hmm … zugegeben: es ist deutlich besser als mit reinem Javascript, aber jetzt manipuliert man mit jQuery Daten des DOM und wo liegt dieser Code? Im Controller? Gehört er hier wirklich hin? Ein Blick in die Dokumentation von JavascriptMVC bestätigt es mir, ja da kommt er hin!

Durch Data-Binding in Flex ist es möglich Views zu entwickeln, von denen der Controller nichts weiss. Ich denke dies ist der richtige Weg um Wiederverwendbarkeit zu erlangen, da der View jederzeit ausgetauscht werden kann, genauso wie der Controller. Mit gängigen Javascript-Frameworks wird das ganze so streng mit einander verwoben, das hier von Wiederverwendbarkeit keine Rede sein kann.

ECMAScript 4

ECMAScript 4 … das sollte einmal ein Javascript-Standard werden:

Though flexible and formally powerful, the abstraction facilities of ES3 are often inadequate in practice for the development of large software systems. ECMAScript programs are becoming larger and more complex with the adoption of Ajax programming on the web and the extensive use of ECMAScript as an extension and scripting language in applications. The development of large programs can benefit substantially from facilities like static type checking, name hiding, early binding and other optimization hooks, and direct support for object-oriented programming, all of which are absent from ES3.

ECMAScript 4 wurde aber aus irgendwelchen politischen Gründen der Browserhersteller verworfen, allerdings erst nachdem Actionscript 3 diesen Standard bereits adaptiert hat. Mir ist es bis heute nicht klar warum, dieser Standard hätte so vieles ändern können. Während Actionscript sich bereits seit guten 5 Jahren wie eine ausgewachsene Programmiersprache anfühlt, fühlt man sich bei Javascript immer noch wie ein Script-Kiddie, dem offenbar keine Grenzen gesetzt sind.

Bei Javascript ist alles möglich und das liegt hauptsächlich am sog. “Prototyping“, dem Vererbungsmechanismus in Javascript. Das Prototyping ist meiner Meinung nach eine Katastrophe, die Dinge zulässt, die in einer objektorientierten Programmiersprache nicht möglich sein dürfen. Und was haben wir statt dem? Dutzende Frameworks, die versuchen genau diese Probleme lösen, in dem mittels Prototyping eine Abstraktion geschaffen wird, um eine OO-Sprache nachzuahmen. Jedes Framework meint das besser zu können als andere Frameworks. Damit ist jede einzelne Klasse, die ich in einem solchen Framework schreibe, eben an dieses Framework gebunden. Mit anderen Worten: Fast jedes Framework bringt seine eigene Programmiersprache mit sich.

Multimedia-Formate

Dazu gibt es nicht viel zu sagen: in Flash brauche ich ein Video oder Musikstück nur in einem Format ausliefern, in der HTML-Welt muss ich Multimedia-Formate für verschiedene Browser in verschiedenen Formaten abliefern. Hier wird so schnell leider keine Javascript Bibliothek Abhilfe schaffen können.

Event-Modell

Das Event-Modell von Javascript ist nicht einheitlich. Der eine Browser unterstützt Event-Bubbling, der andere Event-Capturing und mit jQuery erhalte ich auch ein einheitliches Event-Modell, bei dem ich aber folglich weder Bubbling noch Capturing verwenden darf, weil eben nicht jeder Browser unterstützt wird. Korrigiert mich bitte wenn ich hier falsch liege. Auch hier wird leider kein Framework Abhilfe schaffen können.

Fazit

Wie gut die Aussicht hinsichtlich UI-Komponenten ist, weiss ich nicht. Ich hoffe einfach darauf, dass irgendwann einmal das Thema von kompetenten Entwicklern in die Hand genommen wird und ein reichhaltiges UI-Framework geschaffen wird. Leider ist dies keine einfache Aufgabe, hier sind sicherlich viele Mannjahre an Arbeit erforderlich.

Hinsichtlich Data-Binding ist das AngularJS-Framework sehr vielversprechend. Dieses werde ich mir in nächster Zeit genauer anschauen.

Die Punkte ECMAScript 4, Multimedia-Formate und Event-Modell sind mit einer Javascript Bibliothek oder einem Framework vermutlich nicht so einfach lösbar. Das ist die alleinige Schuld der Browser-Hersteller!

Ich sehne mich nach einer Zukunft ohne Flash, aber in dieser Zukunft muss die HTML-Welt liefern, was in Flash schon seit Jahren Realität ist!