AngularJS bringt für die Entwicklung der Frontends moderner Webanwendungen ein neues Paradigma. Vorbei sind die Zeiten, in denen das UI auf dem Server berechnet wurde und wir uns im Browser ständig mit niederen Aufgaben wie DOM-Manipulationen herumschlagen mussten. Die Zukunft gehört RIAs, deren Frontend komplett im Browser läuft und die mit Techniken wie Data Binding, Model View Controller und Dependency Injection arbeiten. Genau diese Features bringt AngularJS in den Browser.

Wie wurden Webanwendungen bisher entwickelt und warum soll das jetzt nicht mehr gut genug sein? Warum ein Paradigmenwechsel? Nehmen wir zum Beispiel zwei im Java-Umfeld weit verbreitete Frameworks: GWT und JSF. Die Erfahrung zeigt, dass sich mit beiden Technologien mächtige Webanwendungen entwickeln lassen. Allerdings haben aus heutiger Sicht beide auch Nachteile.

In GWT läuft das komplette Frontend im Browser, wird aber in Java entwickelt – sowohl die Logik als auch die Darstellung. Das ist gerade für erfahrene Java-Teams ein großer Vorteil. Mit den neueren Versionen ist es zudem möglich, mit UiBinder das UI auch deklarativ mittels XML zu beschreiben. Eines aber bleibt: Wir entwickeln unsere Webanwendung in der Java-Welt bzw. in einer vorgetäuschten Java-Welt und nicht nativ in der Webwelt. Das hat einen großen Nachteil: Um neue Funktionen der Browser und neue JavaScript-Bibliotheken nutzen zu können, sind wir auf eine Integration in GWT angewiesen (sei es durch GWT direkt oder durch eine Bibliothek), da wir eben nicht die vom Browser nativ unterstützten Sprachen verwenden, sondern diese weggekapselt werden. Jüngst konnte man das gut an der Integration von HTML5-Features beobachten, die in GWT lange auf sich warten ließ.

Bei JSF sieht die Situation ein bisschen anders aus: Auch hier wird HTML gemischt mit eigenen Komponenten zur Beschreibung des UIs verwendet, und die Logik wird in Java implementiert. Die Nachteile bei JSF sind aber andere: Das UI wird auf dem Server berechnet und im Browser nur dargestellt. Fast immer, wenn im UI etwas passiert (z. B. wenn der User etwas anklickt), wird eine Anfrage zum Server geschickt, um das UI zu aktualisieren. Das kann bei schlechten Internetverbindungen, bei Anwendungen, die auch auf mobilen Geräten verwendet werden oder auch bei vielen Änderungen im UI zu einem echten Problem werden. Hinzu kommt, dass Informationen über den Client auf dem Server gespeichert werden müssen. Wir benötigen also ein Session-Management, was wiederum Nachteile mit sich bringt. Zusätzlich zur erhöhten CPU-Last durch die vielen Anfragen, um das UI zu aktualisieren, benötigen wir dadurch auch deutlich mehr Arbeitsspeicher. Skalierung der Server, ob horizontal oder vertikal, wird so nicht nur schwieriger, sondern auch schneller notwendig. Die Rechen- und Speicherkapazitäten moderner Endgeräte, seien es Smartphones, Tablets oder Laptops, werden komplett verschenkt.

AngularJS verfolgt einen völlig anderen Ansatz: Das UI wird ebenfalls deklarativ mit HTML und CSS beschrieben, die UI-Logik wird aber in JavaScript umgesetzt. Das Frontend läuft komplett im Browser. Das Backend weiß bei diesem Ansatz nichts über die Darstellung im Client und dessen Zustand. Da es sich bei Angular um Single-Page-Anwendungen handelt, können diese ihren Zustand selbst verwalten. Das Backend hat dabei zwei Aufgaben, die allerdings nicht zwingend vom selben Server erledigt werden müssen. Zum einen liefert ein Server beim Aufruf der Anwendung oder bei Bedarf auch später statische Dokumente, die der Browser für das Frontend benötigt. Diese Dateien ändern sich selten und können daher von spezialisierten Servern ohne viel Overhead ausgeliefert und vom Client gut gecacht werden. Die zweite Aufgabe des Backends ist es natürlich, die Businesslogik auszuführen und die Anwendungsdaten zur Verfügung zu stellen, beispielsweise über ein REST API. Angular macht dabei keine Vorgaben, wie das Backend auszusehen hat. Es kann also mit beliebigen Technologien umgesetzt werden oder auch ein anderes Paradigma als REST verfolgen.

Betrachten wir das Frontend als eine Art Rich Client, lassen sich HTML, CSS, JavaScript und auch Bibliotheken wie jQuery als Gestaltungsmittel für das UI ganz gut mit Java und SWT vergleichen: sehr low-level! Wer verwendet in Java nicht lieber eine höhere Abstraktion wie JFace oder gar die ­Eclipse RCP mit Funktionen wie Data Binding und Model View...