Entwickler-Rant

Kritik an AngularJS: Acht Dinge, die gegen Angular sprechen

Michael Thomas

© Shutterstock.com/Arcady

Wenn es nach dem Blogger Steve Anderson gehen würde, wäre das JavaScript-Framework AngularJS aufgrund seiner, wie er sagt, „grundlegend schlecht durchdachten Architektur“ schon längst von der Bildfläche verschwunden.

Das JavaScript-Framework AngularJS erfreut sich, vor allem im Enterprise-Umfeld, großer Beliebtheit. Im Oktober letzten Jahres wurde die Version 1.3 veröffentlicht, parallel dazu laufen die Arbeiten an AngularJS 2.0, das von den Machern als „der neue Maßstab für JavaScript-Entwickler“ bezeichnet wird.

Eine Aussage, der Steve Anderson, Blogger auf DevBattles, wohl nicht zustimmen dürfte. Vielmehr freut er sich nach eigener Aussage darüber, dass die Kritik ab AngularJS – zumindest gefühlt  langsam lauter wird. Wenn es nach ihm ginge, wäre das Framework gar schon längst von der Bildfläche verschwunden. Denn für ihn ist AngularJS vergleichbar mit einem billigen Auto, das bereits kaputt vom Band läuft und direkt in die Werkstatt gebracht werden muss. Und dessen dortige Reparaturen nur notdürftig zusammengeschustert werden.

Schauen wir uns die Kritikpunkte Andersons einmal im Detail an:

1. Zwei-Wege-Datenbindung

Die Zwei-Wege-Datenbindung (Two-way data-binding) sorgt für einen automatischen Abgleich zwischen Änderungen im Datenmodell und der Ansicht, wodurch der Boilerplate-Code reduziert werden kann. Allerdings treten, so Anderson, in der Realität Events auf, wenn ein User ein Item anklickt und nicht, wenn das Modell sich ändert. Bei der Arbeit mit AngularJS müsse man deshalb also nicht im Sinne von „Der User hat einen Button angeklickt und den Handler aufgerufen“ denken, sondern im Sinne von „Der User hat einen Button angeklickt, das Modell hat sich geändert, also müssen wir auf Änderungen des Modells achten und den Handler aufrufen“  Für Anderson reiner Nonsens.

Zudem, so Anderson weiter, führt die Zwei-Wege-Datenbindung dazu, dass bei einer in der Anwendung vorgenommenen Änderung hunderte von Funktionen, die Änderung nachverfolgen, ausgelöst werden, was vor allem bei komplexen bzw. größeren Anwendungen und auf mobilen Plattformen nachteilig ist. Stichwort größere Anwendungen: Sauer stößt Anderson in Performancehinsicht auch die Limitierung auf 2000 Watcher auf. Dieser kann zwar durch Ein-Wege-Datenbindung begegnet werden, allerdings handelt es sich für Anderson dabei um eine wenig elegant Lösung.

2. Dependency Injection

In Angular erfolgt die Dependency Injection über den Namen das Arguments und einen Abgleich mit einer Liste bestehender Abhängigkeiten. Die Suche nach einem Variablen-Namen geht für Anderson zwar in Ordnung, das Problem ist ihm zufolge jedoch, dass dies nach der Verkleinerung des Codes nicht mehr funktioniert, da Variablen über den Namen injiziert werden. Dies, sowie die Tatsache, dass AngularJS bei der Deklarierung von Abhängigkeiten auf 5 verschiedene Entitäten, die eigentlich dasselbe sind, zurückgreift, betrachtet Anderson als weiteres Paradebeispiel für die schlecht durchdachte Architektur von AngularJS.

3. Debugging

Das sowieso nicht einfache Debugging wird durch AngularJS weiter verkompliziert, so Anderson. Als Beispiele nennt er u. a., dass Fehler in Bindings nicht feuern oder der Umstand, dass Fehler, die in JavsScript auftreten, von Angulars internem Interceptor gefangen und vom Browser als abgefangene Fehler interpretiert werden. Deshalb, so Anderson weiter, muss dafür gesorgt werden, dass der Debugger bei jeder Ausnahmesituation stoppt, weshalb man wiederum während der Initialisierung alle internen Angular-Ausnahmen durchgehen muss, um alle echten Ausnahmesituationen aufzuspüren.

4. Scope inheritance

Basiert man seine Logik auf Scope Inheritance, ist sie Anderson zufolge sehr schwer zu testen, wird komplizierter und implizit. Geerbte Variablen ähneln globalen Variablen, die bekanntlich leicht zur Fehlerquelle werden können, wenn man sie etwa versehentlich für verschiedene Zwecke nutzt. Last but not least muss man, so Anderson weiter, über deutlich mehr theoretisches Wissen verfügen, z. B. im Hinblick auf die prototypische Vererbung, sowie darüber, wann transclude einen Scope erstellt oder eben nicht.

5. Direktiven

Anderson versteht nicht so recht, warum Direktiven für viele sozusagen den heilige Gral darstellen, da man mit ihnen seiner Meinung nach deutlich mehr Zeit damit verbringt, darüber nachzudenken, WIE man etwas tut, anstatt tatsächlich etwas zu tun. Er hält die Existenz von drei Methoden für unnötig, da eine einzige Methode denselben Effekt erzielen könne. Weitere Probleme sieht er darin, dass manche Funktionen Scope erhalten, manche nicht, einige nur einmal, andere hingegen wiederholt ausgeführt werden. Außerdem müsse man, so Anderson weiter, jedweden Code, selbst ein kleines jQuery-Plug-in, zur Integration in eine Direktive einpacken.

6. Der Faktor Mensch

Anderson zufolge kennen sich aufgrund seiner Komplexität nur wenige wirklich gut mit AngularJS aus. Des Weiteren verstehen Server-Entwickler seiner Ansicht nach nicht, was im Front-End vor sich geht und können den Code nicht lesen. So werde eine „Black Box“ geschaffen, die meist nur von einem Teammitglied verstanden wird  sollte dieses ausfallen oder das Unternehmen verlassen, guckt der Rest in die Röhre.

7. Keine Möglichkeit des serverseitigen Rendering

Da das serverseitige Rendering dem HTML Logik hinzufügt und AngularJS Logik in HTML schreibt, besteht keine klare Trennung – für Anderson ist deshalb „Spaghetti-Code“ die logische Konsequenz . Ein Geschwindigkeitsschub für das Seiten-Rendering oder das SEO lasse sich somit nur dann realisieren, wenn man auf Hacks zurückgreift.

8. AngularJS 2.0

Da AngularJS 2.0 fast von Null an komplett neu geschrieben wird und so keine Rückwärtskompatibilität gegeben ist, werden alle, die zur Zeit mit dem Framework 1.x arbeiten, vor Probleme gestellt. Immerhin, so Anderson, bestätigen die Angular-Macher damit seiner Ansicht nach seine eigene Grundhaltung: Wenn das Framework wirklich gut wäre, warum muss man es dann von Grund auf neu schreiben?

So weit die Kritikpunkte von Anderson, die mitunter etwas pauschal ausfallen. Doch was meinen Sie: Wo hat Anderson Recht, wo schlägt er über die Strenge?

Aufmacherbild: Stop sign von Shutterstock / Urheberrecht: Arcady

Verwandte Themen:

Geschrieben von
Michael Thomas
Michael Thomas
Michael Thomas studierte Erziehungswissenschaft an der Johannes Gutenberg-Universität Mainz und arbeitet seit 2013 als Freelance-Autor bei JAXenter.de. Kontakt: mthomas[at]sandsmedia.com
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "Kritik an AngularJS: Acht Dinge, die gegen Angular sprechen"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Wolfgang
Gast
Mit einigen Aussagen hat Anderson sicher recht, doch die meisten Punkte lassen darauf schließen, dass sich Mr. Anderson nur sehr oberflächlich mit AngularJS beschäftigt hat. Auch wenn die anfangs sehr steile Lernkurve viele Einsteiger abhält, so bietet das Framework zahlreiche, unschätzbare Vorteile gegenüber anderen JS-Libraries. Wäre AngularJS ansonsten so beliebt ? Was das Upgrade auf 2.0 angeht, so muß man die Entwickler gerade für die mangelnde Rückwärtskompatibilität loben. Lieber ein stabiles, zukunftsfähiges Framework, statt Altlasten von einer in die nächste Version zu schleppen. Dafür gibt es leider genug schlechte Vorbilder. Abgesehen davon wird es ein upgrade Modul geben, mit dem… Read more »