Lessons learned: GWT

By | 14. Juli 2011

Ich arbeite seit knapp zwei Jahren mit GWT und habe bereits einiges ausprobiert. Meiner Meinung nach ist GWT eins der genialsten Werkzeuge, die einem Webentwickler gegeben wurden. Aber auch eins, mit dem man sich leicht verrennen kann.

Meine Lieblingskombination ist GWT zusammen mit Grails. Damit bin ich bisher ganz gut gefahren und es macht echt Spaß. Bloß, es gibt immer wieder Situationen, in denen ich mir sage: Na das hättest du aber auch leichter haben können.

Mit GWT neige ich dazu die Oberfläche mit UiBinder und Co. zu erstellen. Am besten auch noch komplett mit Layout. Es ist bequem und dann auch perfekt testbar. Das Ergebnis sind GWT Kompilate in der Größe von 1MB und mehr. Diese JavaScript Dateien wollen erstmal vom Client geladen und verarbeitet werden, was eine gewisse Zeit in Anspruch nimmt. Das neue CodeSplitting Feature erlaubt zwar mittlerweile die Kompilate zu trennen und ein Nachladen zu ermöglichen, aber weitere Probleme bleiben.

Beispiel: UI Monolithen. Wenn der Browser zunächst ein Fragment mit der Größe von 500KB und mehr laden muss, um dann den DOM aufzubauen, merkt der Benutzer das. Denn es dauert länger. Zwar kann man ihm einen kleinen Spinner zeigen, der ihn drauf hinweist, dass die Anwendung gerade etwas tut, aber gut fühlt sich das nicht an. Ziel wäre es dem Benutzer Inhalt zu zeigen, der ihn für die nächsten paar Sekunden beschäftigt, während der dynamische Code im Hintergrund allerlei anderen Kram macht.

Beispiel: Suchmaschinen. Wenn sich die GWT Anwendung in den DOM lädt, dann ist er oft vorher nackt. Den wirklich interessanten Markup Code erzeugt die GWT Anwendung und dieser beleibt für die Suchmaschine unsichtbar.

Beispiel: Dynamische Links. Rendere ich mit GWT eine dynamische Ansicht und möchte daraus auf weiteren Inhalt meiner Internetseite verweisen, muss ich GWT diesen Link irgendwie übermitteln. Da gibt es mehrere Möglichkeiten. Ich kann ein Feld im DOM verstecken und ihn dann über die ID ansprechen, oder ich übertrage die URL per RPC an den Client. Ändert sich aber meine Ansicht (kommt ein weiterer Link hinzu), dann muss zwangsweise serverseitig der Code angepasst werden, was die Entwicklung erschwert.

Beispiel: Formatierung. In der ersten Shop-Version von Snäckbox habe ich eine Klasse geschrieben, die Geldbeträge, Gewichte, Datum usw. formatiert. Der Ansatz war nicht schlecht, bloß absolut überflüssig. Denn die meisten Formatierungen mussten serverseitig ebenfalls implementiert werden, wenn beispielsweise eine Email versendet oder PDF erzeugt wurde. Doppelter Code also. Ich bin dann später dazu übergegangen nur noch formatierte Strings an den Client zu übertragen.

Beispiel: Lokalisierung. Mit GWT ist es einfach zu internationalisieren. Interface definieren, ein paar Annotations verwenden, fertig. Aber, serverseitig passiert das in den meisten Fällen auch. Vielleicht müssen sogar die selben Meldungen übersetzt werden (z.B. Fehlermeldungen). In dem Fall ist es wichtig diese Meldungen bei Änderungen synchron zu halten und bei einer wachsenden Applikation ist es irgendwann nicht möglich den Überblick darüber zu behalten.

Beispiel: Änderungen an der UI. Ändere ich die Farbe einer Linie oder die Schriftgröße, und sehe mir anschließend das Ergebnis im Browser an, muss ich unter GWT wegen einer CSS Lappalie ein paar Sekunden warten. Kommt ganz auf die Anwendungsgröße an. Bei einer Grails-Anwendung ist das Ergebnis schneller da. Auf den Tag gesehen summiert sich die Differenz. Ganz abgesehen davon, sollte das Programm auf den Entwickler warten, nicht umgekehrt.

Mein Fazit: Wenn ich die Möglichkeit habe serverseitig einige der hier beschriebenen Aufgaben zu erledigen, dann würde ich das tun. Insbesondere, was die Formatierung von Werten betrifft. Natürlich ist das von Problemstellung zu Problemstellung unterschiedlich und muss im Einzelfall entschieden werden. Aber Fakt bleibt, dass GWT all die wunderbaren Dinge ermöglicht und den Entwickler „verführt“ Code zu schreiben, der z.B. in Grails viel schneller realisiert werden kann.

Lösungsvorschlag

Ich habe vor einigen Monaten begonnen die GWT Anwendungen auf eine anderen Weise zu entwickeln, als ich es bisher getan habe. Statt große Monolithe zu bauen, die eine komplette UI erstellen, setze ich auf starke Modularisierung der GWT Anwendungen, kurze Ladezeiten und so wenig UI Code, wie möglich. Zusätzlich versuche ich die Client-Anwendung so „dumm“ zu halten, wie es geht. Sie soll weder Meldungen übersetzen, noch Geldbeträge oder Datum und Uhrzeit formatieren können.

Die Stärken von GWT versuche ich aber dennoch so gut es geht zu nutzen: Typisierung, Testbarkeit und RPC.

Ich möchte eine kleine Serie von Artikeln darüber schreiben und werde sie dann nach und nach hier verlinken. Anfangen werde ich mit der Modularisierung von GWT Anwendungen.

P.S.
Die Frage nach der Tauglichkeit in der Praxis, werde ich mit Snäckbox 2.0 beantworten, das in weniger als einem Monat online gehen wird 😉

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.