Darf’s auch ein bisschen schneller sein?! Webanwendungen mit JavaScript

JavaScript ist laut TIOBE Index mittlerweile auf Platz sieben der bekanntesten Programmiersprachen und die Tendenz ist steigend. In der Business IT tut sie sich gegen den Branchenprimus Java aber noch schwer. Dabei ist JavaScript gerade für Webanwendungen ‚state of the art’ und bekannt für schnelle und schicke „Single Page Apps“. Aber warum setzt sich JavaScript bei Unternehmensanwendungen dennoch nicht durch? Und was machen JavaScript Frameworks wie AngularJs oder ReactJs besser als ihre Java Pendants?

Erfahrene Java-Entwickler rümpfen bei dem Gedanken an JavaScript oft die Nase. Sie erinnern sich noch an die Anfänge von JavaScript, als diese Sprache ausschließlich im Browser verwendet wurde, und haben ihr damals den Stempel einer schrecklichen und schwer benutzbaren Programmiersprache gegeben. Mühselige Fehlersuche, schlechte Toolunterstützung, unterschiedliche Browserunterstützung und schlechte bis gar keine Debugging-Möglichkeiten sind nur ein paar negative Argumente aus den Anfangszeiten von JavaScript, die gerne herangezogen werden. Java-Web-Frameworks wie Apache Wicket oder Vaadin bieten bequeme Alternativen, da sie einen Teil der Webtechnologien wegabstrahieren. Im Team ist das Java Knowhow sowieso vorhanden, also  warum nicht auch Java- Web-Frameworks benutzen?

Seit den Anfängen von JavaScript hat sich vieles getan: Es gibt nun eine Vielzahl an Bibliotheken und Frameworks, die Probleme aus früheren Zeiten lösen. Mit NodeJs hat es JavaScript geschafft, eine Programmiersprache für Client- und Serverimplementierungen zu werden. Nichtsdestotrotz ist der Browser das natürliche Territorium von JavaScript. Ich habe bereits Webanwendungen mit Java und JavaScript umgesetzt und möchte nun eine Lanze für JavaScript Webframeworks brechen. Meiner Meinung nach machen sie einige Sachen besser und sind für Webanwendungen besser geeignet.

1. Der schnellste Weg zum Working Prototype

Mit HTML und ein bisschen CSS hat man schnell das Grundgerüst einer Webanwendung erstellt. Fügt man noch ein bisschen JavaScript hinzu oder verwendet sogar noch einige Zeilen AngularJS-Code,  hat man auch schon ein paar Funktionalitäten rudimentär implementiert - zumindest soweit, um etwas vorzeigen zu können und sich erste Feedbacks einzuholen. Für einen Prototypen mit Java habe ich immer länger gebraucht.

2. Große Auswahl an Plug & Play UI-Komponenten

Das hat nicht nur etwas damit zu tun, dass zuerst ein Serverprojekt aufgesetzt werden musste, das Framework integriert und erst dann die ersten Seiten gebaut werden konnten, sondern auch damit, dass ich mich mit reinem HTML und etwas JavaScript an einem riesen Fundus von UI-Komponenten bedienen kann. Ich kann z.B. nach einer „Date Picker“ - Komponente suchen und direkt verwenden, ohne sie zuerst in ein Java-Framework integrieren zu müssen.

3. Einschränkungen in den Schnittstellen von Java-Web-Frameworks

Die Abstraktion der Webtechnologien, die als Vorteil der Java-Web-Frameworks aufgeführt wird, stellt sich bei der Integration neuer bzw. selbst angepasster UI-Komponenten als Nachteil heraus. Ich muss versuchen, die meist auf jQuery basierten Bausteine in das Modell des Java-Frameworks zu zwängen und die angebotenen Eingriffsmöglichkeiten zu nutzen. Das kostet oft Zeit, Geld und Nerven, bis alles zur vollen Zufriedenheit funktioniert. Einer dieser Hooks bei Apache Wicket sind AjaxUpdatingBehaviors. Diese Behaviors können Änderungen an der Webseite auslösen ohne einen kompletten Seitenreload zu triggern. Die verwendeten JavaScript-Bibliotheken bekommen diese aber meist nicht selbstständig mit und man muss manuell dafür sorgen, um z.B. DatePicker zu initialisieren oder andere Komponenten an den neuen Seitenstatus anzupassen.

4. Flüssige User Experience

Letztendlich ist es dem Benutzer egal, mit welchen Frameworks eine Webseite erstellt wird: Für ihn ist vor allem wichtig, dass die Seite schnell aufgebaut wird. Bei Apache Wicket wird die Webseite auf dem Server generiert und dann vollständig an den Browser ausgeliefert. Das frisst nicht nur Ressourcen auf der Serverseite, sondern führt auch dazu, dass der Benutzer warten muss, bis die Webseite generiert, über das Netz gesendet und im Browser angezeigt wird – und zwar jedes Mal, auch wenn sich nur Teile der Webseite ändern.

Bei modernen JavaScript-Frameworks ist das meist nicht der Fall: Der Clientcode verlagert sich hier vom Server auf den Client und wird im Browser ausgeführt. Auf dem Server wird lediglich die Businesslogik ausgeführt und an den Browser werden nur noch die tatsächlichen Daten gesendet. Dieses Vorgehen spart serverseitig Ressourcen und der Benutzer sieht bereits die Webseite, während parallel die Daten vom Server „eingespielt“ werden. Der Benutzer hat das Gefühl schon mit der Anwendung arbeiten zu können und spürt kaum Verzögerungen beim Seitenaufbau.

Fazit

Schnell, elegant und mit wenig Aufwand zum Ziel kommen – der Traum jedes Auftraggebers und Entwicklers – ist mit JavaScript Webframeworks immer leichter zu erreichen. Ein Ende der Entwicklung ist dabei noch lange nicht in Sicht und am Ende profitiert vor allem der Benutzer.