HTML and CSS Reference
In-Depth Information
wird jetzt effizient auf die Clients (Browser) verlagert. Die Kommunikation mit dem Server wird
auf ein Minimum reduziert. Intelligentes Zwischenspeichern (Cachen) und die Einführung von lokal
gespeicherten Daten können die Bilanz noch besser aussehen lassen. GWT bietet neben der übli-
chen Kommunikation mittels Austausch von mit JSON und XML formatierten Daten auch ein ei-
genes Verfahren namens GWT RPC, das das Umwandeln ganzer serialisierbarer Java-Objektbäume
beherrscht. In Bezug auf GWT RPC gilt die Analogie zu RMI mit einem wesentlichen Unterschied:
Während RMI eine generische (und somit nicht schlanke) Laufzeitumgebung für die Interprozess-
kommunikation umsetzt, wird bei GWT RPC im Kompiliervorgang auf die Kommunikationsschnitt-
stelle optimierter JavaScript-Code generiert.
Die HTTP-Spezifikation schränkt die Anzahl der offenen persistenten Verbindungen, die ein Brow-
ser zu ein- und demselben Server aufbauen kann, auf zwei ein. Da JavaScript der Same Origin Police
unterliegt, darf man von einem prinzipbedingten Flaschenhals sprechen. Auch wenn sich Browser
nicht an die Spezifikation halten, ist die Anzahl der Verbindungen dennoch beschränkt, meistens auf
sechs oder acht Verbindungen. Wie wenig das ist, wird erst dann deutlich, wenn man Webanwendun-
gen unter die Lupe nimmt und untersucht, wie viele Requests für die Anzeige einer Seite durchge-
führt werden. Zum Beispiel hat das Laden der Einstiegsseite bei Amazon.de zu beindruckenden 90
Requests geführt (JavaScript, Bilder und CSS-Dateien, die geladen werden). Da nicht alle Anfragen
parallel ausgeführt werden können, entstehen beachtliche Latenzen/Wartezeiten, bis alle Ressourcen
geladen worden sind. Einerseits liegt dieses Ladeverhalten in der Natur von Webanwendungen, an-
dererseits sind Lösungsansätze, die dieses Problem reduzieren, bekannt. Die Anzahl der möglichen
Verbindungen zu erhöhen, würde nur gleichzeitig auch die Last auf dem Server beachtlich erhöhen,
ohne das Problem wirklich zu lösen. Außerdem müssten die Browser entsprechend konfiguriert wer-
den, was nicht immer einfach oder gar möglich ist. Die Lösung des Problems liegt darin, die Anzahl
der notwendigen Verbindungen prinzipiell zu reduzieren. Das Single-Page-Prinzip sorgt schon mal
dafür, dass die Anwendung lediglich einmal geladen wird, und somit führt nicht jede Benutzerak-
tion auf der Webseite zu einem kompletten Neuladen und Rendern der Seite. Des Weiteren können
sowohl CSS als auch JavaScript in die geladene HTML-Host-Seite eingebettet und statische Bilder
zu einem Mosaik zusammengefasst (und clientseitig per CSS Clipping angezeigt) werden. Zudem
besteht zusätzlich die Möglichkeit, Bilder Base64-kodiert ebenfalls in die HTML-Seite einzubetten.
Das Toolkit liefert einen Java-zu-JavaScript-Compiler, der mehr als die eigentliche Übersetzung
durchführen kann. Neben der eigentlichen Transformation ist GWT zudem in der Lage, unter an-
derem die oben genannten Optimierungen vorzunehmen. Der generierte JavaScript-Code kann au-
ßerdem je nach Konfiguration zum Beispiel in einer knappen Form (obfuscated) erzeugt werden. Es
werden mehrere Permutationen der Anwendung generiert, für jede Sprache und jeden Browser, da-
mit dem Anwender das Laden und Ausführen von unnötigem Anwendungscode erspart bleibt. Dem
Toolkit merkt man sehr schnell an, dass es nicht nur Produktionsreife hat, sondern auch tatsächlich
produktiv (von Google) eingesetzt wird. So werden zum Beispiel die generierten Dateien mit (sehr)
