Web-Anwendungen mit Java

Es ist ein weit verbreiteter Irrtum, dass eine Web-Anwendung eine Client-Server-Anwendung ist, die halt nur eine andere Benutzerschnittstelle hat. Die klassische Client-Server-Anwendung und eine Web-Anwendung haben zwar vieles gemeinsam, aber die Unterschiede sorgen dafür, dass ein unbedarftes Herangehen an Web-Anwendungen schnell bestraft wird. Ein Teil der Unterschiede ist technischer Natur, der andere betrifft den Kontext, für den Web-Anwendungen erstellt werden. Ich beleuchte zuerst den technischen Aspekt, danach geht es um die Begleitumstände.

Technische Unterschiede

Ein Hauptunterschied zu normalen Client-Server-Anwendungen ist die Tatsache, dass die Verbindung zwischen Browser und Server zustandslos (stateless) ist. Da aber nur in sehr einfachen Fällen darauf verzichtet werden kann, den aktuellen Status des Clients (etwa die gewählten Produkte eines Web-Shops) von Request zu Request zu sichern, ist hier einiges an Aufwand dafür nötig, aus einer technischen Verbindung ohne Status eine logische Verbindung mit Status zu machen. Hier kommen die ungeliebten Cookies oder Techniken wie URL-Rewriting ins Spiel, mit denen Session-IDs über versteckte Parameter übertragen werden.

Ein weiteres einflussreiches Problem betrifft das Rendering. Wie bei einer normalen Client-Server-Anwendung übernimmt der Client, also der Browser, die Darstellung des GUI. Bei einer normalen Anwendung hat aber das Programmierteam sowohl den Serverteil als auch den Client programmiert und aufeinander abgestimmt. Die Fähigkeiten des Browsers entziehen sich aber zum Teil der Kontrolle des Servers, obwohl am Server über die dynamisch erstellten Webseiten das Aussehen der Benutzerschnittstelle entschieden wird.

Aufwändige Web-Anwendungen verlagern deshalb einen Teil des Renderings wieder auf die Serverseite, indem der Browsertyp abgefragt und die Seiten entsprechend aufbereitet werden. Ein Teil des Zeitgewinns bei der Entwicklung, den der Web-Ansatz verspricht, geht dadurch wieder verloren. Außerdem funktioniert die serverseitige Aufbereitung nur bis zu den nächsten neuen Versionen der verwendeten Browser.

Fast nebensächlich erscheint dagegen das Problem der eingeschränkten Möglichkeiten, die HTML bietet. Moderne GUI-Toolkits mit ihren vielfältigen Widgets und den damit an die Problemkreise angepassten Benutzerschnittstellen sind mit HTML nicht zu erreichen. Aber eine einfache Benutzerschnittstelle muss ja nicht schlecht sein, da weniger oft mehr ist.

Wer jedoch aus der klassischen GUI-Programmierung kommt, tut sich mit HTML recht schwer. Statt GUI-Objekte zu erzeugen und zu manipulieren, muss HTML-Text ausgegeben werden. Weiter unten stelle ich zwar verschiedene Toolkits vor, die den HTML-Text innerhalb von Objekten kapseln, ein Problem bleibt aber immer bestehen: Es gibt (noch) eine gemeinsame Sprache der Programmierer. Oder anders ausgedrückt: Wer einmal beispielsweise eine KDE- oder Swing-Anwendung geschrieben hat, kann ohne übergroßen Aufwand die Seite wechseln, denn Buttons, Labels, Entry Fields gibt's hier wie dort. Bei Web-Anwendungen sieht es dagegen anders aus. Jede Site verwendet einen anderen Ansatz, die sich oft grundlegend in Philosophie und Methoden unterscheiden.

Optisches Design als Komplexitätsfaktor

Nahtlos an das gerade Gesagte schließen sich einige Probleme an, die zwar eher im menschlichen Bereich liegen, aber gelegentlich für umso größere Kopfschmerzen sorgen. Jede Anwendung sollte zwar auf Benutzbarkeit geprüft werden und größere Firmen haben dafür extra Abteilungen, aber das grundlegende Aussehen der Anwendung ist durch das GUI-Toolkit vorgegeben.

Der Vorteil liegt auf der Hand. Wer grafische Anwendungen aus der frühen X11-Zeit mit heutigen KDE- oder Gnome-Anwendungen vergleicht, merkt schnell den Unterschied. Damals musste jede Anwendung anders bedient werden, jede neue Anwendung war ein neues Abenteuer. Heute finde ich ähnliche Grundfunktionalitäten immer an derselben Stelle im Menü über dieselben Shortcuts.

Das Web dagegen ist eher mit der Frühzeit der grafischen Benutzerschnittstellen vergleichbar. Designer bestimmen das Aussehen und die Benutzerführung - und damit prallen zwei Welten aufeinander, denn das FFF-Prinzip (Form follows Function) des typischen Programmierers wird von Designern oft nicht geteilt. Unabhängig davon sorgt aber allein die Tatsache, dass neben den Programmieren noch weitere Interessengruppen an einem Programm mitwirken, zu Verzögerungen. Irgendwann ist bekanntlich immer der Punkt gekommen, an dem mehr Mitarbeiter ein Projekt verzögern, statt zu beschleunigen.

Ein Argument für die Designer-Seite ist der Einsatzzweck von Web-Anwendungen. Solange sie für den Verkauf von Produkten eingesetzt werden, ist eine Investition auf dieser Seite sinnvoll. Aber mehr und mehr normale Anwendungen finden ihren Weg auf die (Intranet-)Applikationsserver, und hier ist die schnelle Erstellung und einfache Benutzbarkeit wichtiger als ein schönes Aussehen.

Abbildung 1: So sieht das MVC-Modell aus.