Framework-Müdigkeit im JavaScript-Umfeld

Ein JavaScript-Framework für alles?
Kommentare

Wenn es um den Vergleich zwischen JavaScript und anderen Programmiersprachen geht, scheint es, als bräuchte JavaScript ständig eine Extrawurst – nicht nur, was die Standardisierung der Sprache angeht, sondern auch, wenn es um das passende Framework geht. Denn während Sprachen wie Objective-C, Ruby oder Java seit Jahren auf ein und dasselbe Framework bauen, gibt es neue JavaScript-Frameworks an allen Ecken und Enden. 

Und selbst wenn man glaubt, endlich Framework-Frieden gefunden zu haben – in diesem Fall AngularJS – wird das durch anstehende neue Versionen ohne Rückwärtskompatibilität und Upgrade-Pfad gleich wieder über den Haufen geworfen. Doch warum gibt es überhaupt diese Framework-Müdigkeit? Allen Pike ist dem nachgegangen

Woher kommt die JavaScript-Framework-Müdigkeit?

Angeblich sind To-Do-Listen die komplexesten JavaScript-Apps, die man erstellen kann, bevor das nächste „In“-Framework um die Ecke kommt. ToDoMVC vergleicht Frameworks unter dem Gesichtspunkt, wie sie To-Do-Projekte angehen; derzeit finden sich Beispiele von 63 verschiedenen JavaScript-App-Frameworks – und wöchentlich kommen zahlreiche Pull-Requests für neue Frameworks hinzu.

Doch woher kommt diese Instabilität im JavaScript-Umfeld? Das größte Problem dürfte dabei der Browser sein: die meisten Entwickler, die JavaScript schreiben, schreiben es, weil sie es müssen, nicht weil sie es wollen. Dazu bringen sie zahlreiche verschiedene Hintergründe mit und haben eine Vielzahl von Ideen, die mehr oder weniger gut zusammenpassen. Zwar ist gegen Vielfältigkeit in der Entwicklercommunity nichts einzuwenden, allerdings sorgt das auch dafür, dass viel ausprobiert und viel von anderen übernommen wird – und schon steht man vor dem Framework-Chaos.

Dazu kommt, dass Browser kontinuierlich (und zum Teil auch unvorhersehbar) verbessert werden und sich JavaScript-Frameworks so schneller anpassen müssen, als dies bei anderen Sprachen der Fall ist. Oder, wie Allen Pike es ausdrückt:

Unfortunately, while the community is busy driving new features and new frameworks, the browser is busy killing them.

Ein weiteres Problem dabei ist, dass schwergewichtige Frameworks kaum eine Chance haben, im Kampf um die Framework-Krone zu bestehen, weil gerade für Mobile Apps Latenz, Memory und Ladezeiten eine wichtige Rolle spielen. Zudem sind sie oft nicht leicht zu lernen und zu maintainen.

Mikroframeworks to the rescue?

Für viele lautet hier die Lösung: Mikroframeworks. Doch während die zwar in der letzten Zeit durchaus an Popularität zugelegt haben, sind auch sie nicht das Allheilmittel. Zum einen sind sie oft so leichtgewichtig, dass sie zwar nicht auf die Ladezeit schlagen, dafür aber auch nicht gerade für ein umfangreiches Problemrepertoire eine Lösung bieten.

Zum anderen stehen JavaScript-Einsteiger und diejenigen, die keine Vollzeit-clientseitigen Entwickler sind vor der Frage, welches Framework das richtige ist. Denn während sich zwar mit dem Mischen von Komponenten aus mehreren Mikroframeworks gute Ergebnisse erzielen lassen, können auch sie nicht alle Probleme lösen.

Dementsprechend ist es fast unmöglich, ein Framework zu wählen, mit dem man komplett glücklich ist. Und, ironischerweise, sorgt genau diese permanente Unzufriedenheit mit dem Framework der Wahl dafür, dass noch mehr Frameworks aus dem Boden schießen.

AngularJS, die Lösung aller Probleme?

Viele Entwickler folgen dem Muster, ein neues Framework nicht zu lernen bis es zu einem der beliebtesten, angeblich besten JavaScript-Frameworks geworden ist. Derzeit scheint es, nach über zehn Jahren, so, als würde sich hier langsam ein eindeutiger Sieger herauskristallisieren: AngularJS.

Doch während AngularJS von vielen Entwicklern als eine Art Heilsbringer gesehen wird, ist auch dieses Framework nicht die Lösung aller Framework-Probleme. Zum einen, weil es an vielen Stellen unnötig komplex ist und so beispielsweise für eine schwächere Performance sorgen kann, zum anderen, weil AngularJS 2.0 nicht mit den früheren Versionen kompatibel ist und es nicht mal einen einfachen Upgrade-Pfad gibt.

So sorgt also auch das momentane „In“-Framework für Verwirrung und neue Probleme. Es scheint also, als dürfe man sich nicht wundern, wenn die Framework-Situation in JavaScript auch weiterhin unübersichtlich bleibt und alle paar Tage ein neues Framework angepriesen wird. Denn, wie Allen Pike erklärt:

Perhaps we should just resign ourselves to it always being this way. While I’ve long argued that creating your own JavaScript framework out of a microframework and a DOM library is madness, maybe it’s the least bad option.

Aufmacherbild: do not disturb von Shutterstock / Urheberrecht: bopav

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -