Zeit für Neues: Von Wicket zu Angular – einfacher als gedacht

Print Friendly, PDF & Email

In den vergangenen Jahren ging der Trend in der Client-Entwicklung weg vom serverseitigen Rendern hin zu clientseitigen Frameworks. Wer als Java-Entwickler nie richtig warm mit Javascript wurde, blieb trotzdem bei bewährten Frameworks wie Wicket. Mit Angular steht jetzt eine Alternative zur Verfügung, die auch hartgesottenen Java-Entwicklern entgegenkommt.

Angular bietet einem Java-Entwickler endlich eine Plattform, die sich gar nicht so sehr von der serverseitigen Welt unterscheidet. Durch TypeScript als Programmiersprache erhält man Typsicherheit mit Klassen und Objekten sowie Module mit Namenräumen ähnlich wie in Java. Angular selbst bringt eine Reihe von Funktionen mit, die den Umstieg weiter vereinfachen:

  • Ein Dependency-Injection-Framework als Ersatz für Spring oder CDI,
  • Annotationen, die mächtige Funktionalität deklarativ zur Verfügung stellen,
  • Komponenten als Grundlage für die UI-Entwicklung wie in Wicket sowie
  • Komponentenbasierte Unit-Tests ähnlich wie mit dem Wicket-Tester

Für einen Wicket-Entwickler fühlen sich viele Konzepte sehr bekannt an. Angular geht aber in vielen Details weit über das hinaus, was mit Wicket möglich ist. Ich möchte hier aber nicht alle Features aufführen, sondern mich auf diejenigen konzentrieren, die mir besonders gut gefallen und die ich noch als Schwächen einstufe.

Was gefällt mir besonders gut?

Es ist erstaunlich, mit wie wenig Code sich komplexe Komponenten entwickeln lassen. Angular bietet viele Funktionen, die sowohl einfach einzusetzen als auch mächtig in ihrer Wirkung sind. HTML-Templates werden in Angular mit Code angereichert. Als Wicket-Purist mag man das nicht mögen. Jedoch entfaltet hier wenig Code sehr viel Wirkung. So genannte Direktiven und Pipes bieten mächtige Werkzeuge, um knapp auszudrücken, wie sich die Oberfläche verhalten soll, während die Implementierung dieser Funktionalität in TypeScript-Dateien bleibt.

Besonders gut gefällt mir die asynchrone Verarbeitung von Daten mit Observables. Angular integriert die Bibliothek ReactiveX für Javascript und bietet dadurch elegante Lösungsmöglichkeiten, wie man zum Beispiel Daten von mehreren Quellen laden und an mehreren Stellen in der UI konsistent anzeigen kann.

Eine Benutzeroberfläche in Angular besteht ausschließlich aus ineinander verschachtelten Komponenten. Dieser Ansatz hat sich mittlerweile auch in der Javascript-Welt durchgesetzt. Denn durch Komponenten lassen sich Redundanzen vermeiden und es wird leichter, kleinere, in sich geschlossene und gut zu testende Einheiten zu entwickeln. Eine komplexe Anwendung sinnvoll in Komponenten aufzuteilen, ist jedoch nicht einfach. Als Wicket-Entwickler ist man aber daran gewöhnt und fängt sofort damit an, sich eine Bibliothek von wiederverwendbaren Komponenten aufzubauen.

Das Modul-System von Angular unterstützt eine saubere Unterteilung der Funktionalität einer Anwendung in einzelne, voneinander möglich unabhängige Module. Dieser Ansatz vermeidet zum einen Abhängigkeiten quer durch den Code und ermöglicht es zum anderen, Module erst bei Bedarf nachzuladen, um die initiale Ladezeit zu verringern.

Ein Schwachpunkt vieler Frameworks für die Webentwicklung ist die leichte Testbarkeit des Codes. Angular hingegen hat das Testen fest integriert, sowohl beim Entwicklungsprozess als auch im Code. Schon bei der Erstellung einer neuen Komponente wird eine passende Test-Datei erzeugt. Und durch klare Vorgaben (Karma, Jasmine) und eine durchgehende Integration wird der Sonderfall nun, keinen Test zu schreiben.

Auffallend ist, dass Angular nicht nur die Bibliotheken zur Verfügung stellt, sondern durch eine eigene Kommandozeilen-Schnittstelle den vollständigen Entwicklungsprozess steuert. Mit wenigen npm- und ng-Befehlen ist eine neue Anwendung aufgesetzt und lokal einsatzbereit und lauffähig.

Schließlich steht eine umfangreiche und gut zu lesende Dokumentation zur Verfügung, die wenige Fragen offen lässt. Auch der Buchmarkt bietet Bücher, die einen schnellen Einstieg ermöglichen.

Wo sehe ich Schwächen?

Trotz aller Stärken von Angular gibt es Bereiche, die ich gegenüber der altgewohnten Welt als Rückschritte begreife.

Angular erfordert viel Boilerblate-Code zur Konfiguration der Module und Routen. Unangenehm wird dies in den Komponenten-Tests. Der Code, um einen einfachen Test aufzusetzen, ist häufig umfangreicher als der eigentliche Test. Jedes Refactoring der Komponentenstruktur erfordert Anpassungen an den Tests. Im Vergleich zu den Komponententests mit Wicket und dem Wicket-Tester sinkt dadurch die Motivation, gründliche Tests zu schreiben.

Die Unterstützung für Internationalisierung, also mehrsprachige Anwendungen, ist im Vergleich zu Wicket eher dürftig. Auch wenn sich die Situation in der neuen Version Angular 5 etwas verbessert, empfinde ich den Umgang mit mehrsprachigen Anwendungen in Wicket erheblich einfacher (bis hin beispielsweise zu mehrsprachigen URLs für dieselben Seiten). Mein Hauptkritikpunkt ist der statische Ansatz, der es erfordert, für jede Sprache die Anwendung getrennt zu bauen und zu deployen.

Wenn man mehr als eine Anwendung in Angular bauen möchte, kommt schnell der Wunsch nach einer eigenen Bibliothek mit wiederverwendbaren Komponenten und Services auf. Grundsätzlich ist dies zwar möglich, jedoch nicht trivial umzusetzen.

Schließlich leiden Angular-Anwendungen unter dem Grundproblem aller modernen Single-Page-Anwendungen: Der Start der Anwendung benötigt in der Regel mehrere Sekunden, bis alle Ressourcen geladen sind. Für „richtige“ Anwendungen ist das kein großes Problem. Für einzelne Webseiten, die suchmaschinen-optimiert ausgeliefert werden sollen, jedoch schon. Denn je länger die Auslieferung einer Seite benötigt, desto schlechter wird sie bewertet – die Anwender wollen schließlich nicht warten. Auch wenn es hier Lösungsansätze für serverseitiges Rendern gibt (Angular Universal), sollte man sich fragen, ob hierfür das gute alte rein serverseitige Rendern nicht der bessere Ansatz ist.

Fazit

Seit der Veröffentlichung von Angular 2 (4, 5) gibt es für Java-Entwickler noch weniger gute Gründe, sich von Client-Frameworks fernzuhalten – vor allem dann, wenn man full-stack arbeiten möchte, also von der Oberfläche bis in die Datenbank. Angular ist ein modernes, wohl durchdachtes und funktionsreiches Framework. Es macht Spaß, es zu lernen und damit zu entwickeln.

Es bleibt abzuwarten, wie lange Angular sich als beliebtes(tes) Framework wird halten können. Meine Einschätzung ist, dass sich die Innovationsrate auf der Client-Seite verlangsamen wird. Angular erscheint mir daher als UI-Framework eine sehr gute Wahl für jeden Java-Entwickler.