Frameworks oder: „Wer die Wahl hat, hat die Qual“

Enterprise Tales: Welches JavaScript-Framework passt zu mir?

Lars Röwekamp, Sven Kölpin

© Software & Support Media

Noch vor wenigen Jahren von vielen Enterprise-Entwicklern als Unheil bringendes Voodoo abgetan, gewinnt JavaScript in modernen Webanwendungen mehr und mehr an Bedeutung. Entsprechend groß ist auch der Zoo an wunderverheißenden Frameworks, aus denen es das passende zu wählen gilt. Wie so oft im Leben gilt leider auch hier: „Wer die Wahl hat, hat die Qual“.

Neulich auf dem Firmenflur: Mein Kollege Sven Kölpin – seines Zeichens „gebürtiger“ Enterprise-Web-Developer – und ich unterhalten uns über die Wahl des „richtigen“ JavaScript-Frameworks. Ein Gespräch, das meinen Horizont und meine Toleranz gegenüber JavaScript deutlich erweitert hat und das ich deshalb auch den Lesern dieser Kolumne nicht vorenthalten möchte.

W-JAX 2019 Java-Dossier für Software-Architekten

Kostenlos: 30+ Seiten Java-Wissen von Experten

Sie finden Artikel zu EnterpriseTales, Microservices, Req4Arcs, Java Core und Angular-Abenteuer von Experten wie Uwe Friedrichsen (codecentric AG), Arne Limburg (Open Knowledge), Manfred Steyer (SOFTWAREarchitekt.at) und vielen weiteren.

 

Fancy UI vs. Single-Page-App

Als Enterprise-Entwickler bin ich es gewohnt, eher in Dekaden als in Monaten zu rechnen. Hat man sich einmal für eines der etablierten Frameworks, wie Java EE oder Spring, entschieden, kann man relativ sicher sein, dass es dieses auch in den kommenden Jahren noch geben wird. Anders dagegen im Dschungel der JavaScript-Frameworks – oder wer erinnert sich noch an die Marktführer von 2010: Prototype UI und script.aculo.us. Wie also wähle ich das passende Framework und wie stelle ich sicher, dass mich die Wahl nicht über kurz oder lang in eine Sackgasse führt?

Zunächst einmal muss ich für mich die Frage klären, was ich mit dem Framework überhaupt erreichen möchte. Geht es eher um UI-Effekte, wie zum Beispiel Drag and Drop und Pop-up-Dialoge, oder soll eine Single Page Web Application (SPA) erstellt werden, deren Logik zu großen Teilen auch direkt auf dem Client ausgeführt wird. Im ersten Fall steht die Manipulation des DOM-Baums im Vordergrund, im zweiten Fall wird das JavaScript auch zur Umsetzung von Businesslogik herangezogen. Der Trend geht dabei mittlerweile mehr und mehr zu SPAs über.

Serverseitiges Rendering plus fancy UI

Serverseitiges Rendering ist der traditionelle Weg, Webanwendungen zu entwickeln. Über die letzten Jahre sind mit Frameworks wie JSF in diesem Bereich recht solide Werkzeuge entstanden. Diese Art der Entwicklung bietet vor allem einen riesigen Vorteil: Abstraktion. Webanwendungen können häufig ohne tiefgehende Kenntnisse über die eigentlichen Webtechnologien geschrieben werden.

Die Entwicklung von serverseitig gerenderten Webanwendungen bedeutet heutzutage aber keinesfalls mehr, dass ein Benutzer am Ende mit einer statischen 90er-Jahre-Webseite konfrontiert wird. Vielmehr entwickelt man „Rich Internet Applications“, also Webanwendungen, die ein aus Desktopanwendungen bekanntes Interaktionsverhalten ermöglichen, aber eben im Browser laufen. Wie das? Das desktopähnliche Verhalten erreicht man über den Einsatz von JavaScript und Ajax. Die Rolle von JavaScript ist hierbei in erster Linie die Manipulation des DOM-Baums, um so eine interaktive Benutzeroberfläche zu schaffen (Dialoge, Drag and Drop, …). Der Einsatz der Bibliotheken jQuery und jQuery-UI hat sich hierbei zum Quasistandard entwickelt. Durch die zusätzlichen Abstraktionsebenen der serverseitigen Frameworks (z. B. Primefaces für JSF) hat der Entwickler aber in der Regel keine direkte Berührung mit den Webtechnologien und den unter der Haube verwendeten JavaScript-Bibliotheken.

Trotz teilweise recht großer JavaScript-Codebasis wird JavaScript bei diesem Ansatz nahezu ausschließlich zur Umsetzung von View-Logik – meist realisiert durch gekapselte jQuery-Funktionen – verwendet. Weil die Komplexität von JavaScript bei der serverseitigen Entwicklung also eher überschaubar ist, wird das ganze Thema häufig stiefmütterlich behandelt, oder eben wie im Falle von JSF komplett in externe Bibliotheken ausgelagert. JavaScript ist bei der serverseitigen Entwicklung eher ein Nebenprodukt als ein ernstgenommener Bestandteil der Anwendung.

SPA aka clientseitiges Rendering

So weit, so gut? Was ist nun aber bei Single Page Web Applications anders? SPAs sind die nächste Evolutionsstufe von Webanwendungen. Sie bestehen nur aus einer einzigen HTML-Seite, deren Inhalt bei Bedarf dynamisch nachgeladen wird. Die Rolle von JavaScript hat sich hierbei drastisch geändert: Es steht nun nicht mehr die DOM-Manipulation, sondern die Umsetzung von Businesslogik im JavaScript-Code im Vordergrund. Der Server dient nur noch als zentraler Datenspeicher und wird in den meisten Fällen statuslos implementiert (RESTful-Ansatz). Da der Server also nur noch Datenlieferant ist und nicht mehr die Aufgabe des Erzeugens von HTML-Fragmenten übernimmt, muss auch dieser Teil vom JavaScript-Code im Browser übernommen werden (z. B. das Erzeugen einer HTML-Tabelle aus Kundendaten). Aus diesem Grund spricht man hier vom clientseitigen Rendering.

Diese veränderte, viel bedeutsamere Rolle von JavaScript hat Auswirkungen auf den gesamten Entwicklungsprozess und birgt eine Menge neue Herausforderungen. Am wichtigsten ist die Auswahl des passenden SPA-Frameworks, was sich leider nicht als trivial erweist.

Das größte Problem ist die Kurzlebigkeit und die damit verbundene Hypegefahr in diesem Bereich. Anders als beim serverseitigen Ansatz ist die Entwicklung von rein clientseitigen Webanwendungen eine noch recht junge Disziplin, weshalb hier ein riesiges Entwicklungspotenzial vorliegt. Aus diesem Grund konnte sich in den letzten fünf Jahren keines der vorhandenen SPA-Frameworks eindeutig durchsetzen. Zwar hat Google mit AngularJS kurzfristig den Anschein erweckt, endlich eine solide Lösung am Markt zu etablieren. Dieser Trend ist aber seit der Veröffentlichung von ReactJS (Facebook) wieder stark rückläufig. Das hat vor allem zwei Gründe. Erstens wird es mit der nächsten Version von AngularJS (2.0) keine hundertprozentige Rückwärtskompatibilität zu den Vorgängerversionen geben, was die vorhandene Nutzerbasis selbstverständlich stark verunsichert hat. Zweitens liefert ReactJS ein revolutionäres (HTML in JavaScript) und performantes (Virtual DOM) Programmiermodell, das eine viel geringere Komplexität und Lernkurve als AngularJS aufweist. Deshalb ist es nicht unwahrscheinlich, dass sich die Community in den nächsten Jahren eher in Richtung von ReactJS orientieren wird. Es bleibt in jedem Fall festzuhalten, dass sich die Schnelllebigkeit der SPA-Frameworks vermutlich auch in den nächsten Jahren noch nicht wesentlich verändern wird. Die Umsetzung rein clientseitiger Lösungen, vor allem im Bereich von Enterprise Applications, ist also zum aktuellen Zeitpunkt noch mit einem gewissen Risiko verbunden.

Umdenken ist angesagt

Die Entwicklung von Single Page Applications erfordert ein Umdenken im bisher gewohnten Entwicklungsprozess. Wie eingangs erwähnt, ist JavaScript bei SPAs ein Hauptbestandteil der Entwicklung und kein Nebenprodukt, das unter Umständen sogar vor dem Entwickler versteckt werden kann. Die Auswirkungen dieser Tatsache sind weitreichend und fangen bei der Teamzusammensetzung an. In den seltensten Fällen gibt es im Team bereits Experten im Bereich von SPAs und selbst wenn, reicht die Erfahrung durch die erwähnte Schnelllebigkeit der Frameworks meistens nur auf wenige Jahre zurück. Auch die Lernkurve für JavaScript als solches darf nicht unterschätzt werden. Die Sprache erlaubt aufgrund ihrer Dynamik extrem viel, was bei wenig erfahrenen Entwicklern häufig zu unerwarteten Nebeneffekten führt. Die neue JavaScript-Version (ECMAScript 2015) verspricht zwar durch zusätzliche Sprachfeatures einen einfacheren Einstieg, nichtsdestotrotz müssen grundlegende Konzepte neu erlernt werden. Bei der Projektplanung für eine SPA müssen diese Tatsachen unbedingt berücksichtigt werden, weil die Menge der technisch bedingten Probleme mit hoher Wahrscheinlichkeit ansteigen wird. Auch langjährige Entwickler sind im Bereich der Single Page Applications heutzutage häufig eher Pioniere als erfahrener Senior Developer.

Die neue Rolle von JavaScript hat auch Auswirkungen auf andere Bereiche der täglichen Entwicklung. Die tragende Rolle des Frontend-Codes erfordert eine feste Integration in den Build-Lifecycle. Hier müssen geeignete Tools (Grunt, gulp, Webpack …) evaluiert werden. Ähnlich wie bei den SPA-Frameworks gibt es auch in diesem Bereich noch keine Patentlösung, sondern lediglich Trends und Ideen. Nicht unerwähnt soll an dieser Stelle das Thema Testen bleiben – die hierfür existierenden Tools sind mittlerweile mindestens auf dem gleichen Level wie man es aus Java gewohnt ist. Zusätzlich bieten die meisten SPA-Frameworks extrem gute Möglichkeiten, testbaren Code zu entwickeln.

SPA-konforme Architekturen

Neben den Veränderungen im Frontend hat die Entwicklung von SPAs auch Auswirkungen auf die Gesamtarchitektur einer Anwendung. Auf der Serverseite müssen idealerweise saubere RESTful-APIs zur Verfügung gestellt werden. Diese sind häufig Grundvoraussetzung für ein problemloses Zusammenspiel zwischen Server und SPA-Framework. Die Entwicklung einer richtigen RESTful-Architektur ist für unerfahrene nicht trivial, weil man nicht service-, sondern ressourcenorientiert denken muss. Zusätzlich erzeugen Themen wie Validierung und Authentifizierung neue Herausforderungen.

Eine letzte zu erwähnende Herausforderung bei der Verlagerung des Renderings auf die Clientseite ist das Thema Performanz. Wie eingangs erwähnt, werden bei SPAs die Ansichten (das HTML) erst im Browser generiert, was bei dem Benutzer häufig den Eindruck eines langsamen ersten Seitenaufbaus bewirkt. Um diesem Problem entgegenzuwirken, wird die initiale Seite einer SPA häufig auf dem Server vorgerendert, sodass beim ersten Request stets eine fertige HTML-Seite an den Client übermittelt wird. Auf dieser setzt ein SPA-Framework dann im zweiten Schritt auf. Der Nachteil dieses Ansatzes: Es muss serverseitig JavaScript-Code ausgeführt werden (z. B. mit Node.js oder in Java mit Nashorn), was eine weitere technische Komplexitätsstufe in ein Projekt bringt. Allerdings lassen sich durch das initiale serverseitige Rendering auch weitere Herausforderungen von SPAs, zum Beispiel Search Engine Optimization (SEO) oder Seitencaching, leichter lösen.

Fazit

Moderne Webanwendungen ohne JavaScript sind heute kaum noch vorstellbar. Bei der Wahl des richtigen Frameworks gilt es zunächst einmal zwischen „Fancy UI“ und „Single Page Web Application“ zu unterscheiden. Hat man sich für eine der beiden Varianten entschieden und ein scheinbar passendes Framework gefunden, sollte man zusätzlich die Performanz und Testbarkeit hinterfragen, um auch langfristig mit dem Framework glücklich zu werden.

Abschließend ist auf jeden Fall auch ein tieferer Blick auf die zum Framework zugehörige Community und deren Aktivität zwingend erforderlich. Eine große und aktive Community ist zwar noch kein Garant für ein langlebiges Framework, erhöht aber auf jeden Fall die Chancen.

Als Fazit kann festgehalten werden, dass wir uns derzeit am Anfang einer sehr spannenden Entwicklung befinden. Sowohl mein Kollege Sven Kölpin als auch ich sind uns sicher, dass wir in den kommenden Monaten noch viel Positives im Umfeld der JavaScript-Frameworks erwarten dürfen. In diesem Sinne: Stay tuned …

Verwandte Themen:

Geschrieben von
Lars Röwekamp
Lars Röwekamp
Lars Röwekamp ist Gründer des IT-Beratungs- und Entwicklungsunternehmens open knowledge GmbH, beschäftigt sich im Rahmen seiner Tätigkeit als „CIO New Technologies“ mit der eingehenden Analyse und Bewertung neuer Software- und Technologietrends. Ein besonderer Schwerpunkt seiner Arbeit liegt derzeit in den Bereichen Enterprise und Mobile Computing, wobei neben Design- und Architekturfragen insbesondere die Real-Life-Aspekte im Fokus seiner Betrachtung stehen. Lars Röwekamp, Autor mehrerer Fachartikel und -bücher, beschäftigt sich seit der Geburtsstunde von Java mit dieser Programmiersprache, wobei er einen Großteil seiner praktischen Erfahrungen im Rahmen großer internationaler Projekte sammeln konnte.
Sven Kölpin
Sven Kölpin
Sven Kölpin ist Enterprise Developer bei der open knowledge GmbH in Oldenburg. Sein Schwerpunkt liegt auf der Entwicklung webbasierter Enterprise-Lösungen mittels Java EE.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: