5 Gründe gegen AngularJS
Kommentare

AngularJS ist das JavaScript-Framework der Stunde, daran lässt sich nicht rütteln. Alle Welt spricht darüber und lobt seine Konzepte, die es für Enterprise-Applikationen geradezu prädestiniert erscheinen lassen. Die integrierten Unit-Testing-Funktionalitäten, Dependency Injection von Haus aus tun ihr übriges. Und das mit Google ein starker Partner an der Seite steht, der zwar bekannt dafür ist, beliebte Technologien mir nichts, dir nichts in der Versenkung verschwinden zu lassen, aber eben auch für Qualität steht, tut sein übriges. Es ist also abgemacht – AngularJS ist super! … oder etwa nicht?

5 Bad Ideas of AngularJS

Lars Eidnes ist Entwickler aus Norwegen. Er hat beinahe das gesamte vergangene Jahr damit zugebracht, ein großes Projekt auf Basis von AngularJS umzusetzen – daher traut er sich zu, ein gewisses Wissen rund um das Framework aufgebaut zu haben. Eben dieses Wissen und die gesammelte Erfahrungen verleiten ihn zu einer überraschenden aber klaren Aussage:

Whatever the reason is for Angulars popularity, it isn’t that it’s a great framework.

So sammelt er die Dinge, die Angular in seinen Augen falsch macht – und kommt am Ende auf 5 schlechte Ideen und titelt: AngularJS: The Bad Parts.

Von schlechten Ideen und Bad Practices

Seine Bad Idea #1 ist das Dynamic Scoping in AngularJS. Denn das kann, wie er in einem Beispiel auf JSFiddle darstellt, zu einem ungewöhnlichen Problem führen. Füll man in dem verlinkten Beispiel das erste Input-Feld zuerst aus, dann wird der Wert auf das zweite Feld übertragen. Tippt man anschließend im zweiten Feld weiter, wird der Wert zurückgegeben ins erste Feld.

So weit, so gut. Tippt man nach dem Laden der Seite jedoch erst im zweiten Feld, so passiert gar nichts. Das liegt an der Terminologie von AngularJS und dem Handling von verschachtelten Direktiven, auf die er sehr ausführlich eingeht.

Seine Bad Idea #2 betrifft das DI – genauer gesagt die Tatsache, dass die Dependency Injection auf dem Namen des Parameters basiert. Sobald man den Quellcode durch den Minifier jagt, wird er dadurch allerdings unbrauchbar.

Die Bad Idea #3 betrifft das Data Binding, das in AngularJS bekanntermaßen in beide Richtungen funktioniert und seiner Erfahrung nach zu zahlreiche Problemen führen kann:

A rule of thumb established by the Angular community is that one should keep the number of such data bindings under 2000. The number of bindings is actually not the whole story: Since each scan through the object graph might trigger new scans, the total cost of any change actually depends on the dependency graph of the application.

Das Problem sei, dass man schnell auf 2.000 oder mehr Bindings käme. Zwar biete das im Oktober veröffentlichte AngularJS 1.3 per Default eine Lösung für das Problem – das kratze jedoch nur an der Oberfläche.

Die Bad Ideas #4 und #5 bauen indes aufeinander auf – mit dem gemeinsamen Nenner, dass AngularJS in vielen Bereichen einfach unnötig komplex sei und sich das unter anderem darin niederschlage, dass eine aus JavaScript bekannte Terminologie in einigen Bereichen – wie beispielsweise in den „Constructor Functions“ – in der Dokumentation zurechtgebogen wird, um zu beschreiben, was in AngularJS passiert.

Durchblick oder Nörgelei?

In seinem Fazit schließt er, dass AngularJS tief liegende Probleme habe – zumindest in der Art, in der es im Moment vorliegt. Vielleicht führt der Weg, den man mit Angular 2.0 einschlägt, in die richtige Richtung. Die Situation zeige seiner Meinung nach aber auch ein anderes Problem auf, das nicht nur auf den Bereich der JavaScript-Frameworks zutrifft:

On the one hand, it’s really hard to evaluate such a project without spending a long time using it. On the other hand, many people like to recommend projects they haven’t used in any depth, because the idea of knowing what the next big thing is feels good. The result is that people choose frameworks largely based on advice from people who don’t know what they’re talking about.

Ob er mit seiner Kritik am Ende nun richtig liegt oder ob man über die eine oder andere Sache nicht hinwegsehen könnte, ist nun eine Frage des Ermessens der Entwickler, die mit AngularJS arbeiten wollen oder müssen. Fakt ist, dass er mit vielen Kritikpunkten nicht alleine dasteht.

Auf der anderen Seite verweist er auf eine wirklich wichtige Frage: Wie oft wählen wir eigentlich ein Framework auf Basis von Empfehlungen, ohne es einer eingehenden Prüfung zu unterziehen?

Das führt uns natürlich zu zwei Fragen: Wie kamt ihr eigentlich zu AngularJS … und seht ihr es wie Lars Eidnes, oder liegt der Mann aus Trondheim mit seiner Kritik daneben?

Aufmacherbild: Divorce Heartache Concept. von Shutterstock / Urheberrecht: Crystal Eye Studio

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -