Vor einigen Wochen kam bei mir das Thema Web-Sockets an. Das ist so eine Art Rück-Kanal, den ein Browser für den Web-Server öffnen kann. Damit muss dann ein Browser nicht immer nur aktiv Inhalte vom Server anfordern (Pull), sondern der Server kann ebenso Daten aktiv dem Browser asynchron mitteilen (Push). Eine Technologie ähnlich SMS und Push-Mail also. Da stellt sich mir doch gleich die Frage, warum man überhaupt noch etwas ohne HTML/HTTP machen sollte.

Profitieren von Web-Sockets werden in erster Linie Anwendungen mit Echtzeit-Charakter: Online-Kooperations-Software wie Google Docs oder Chat-Systeme, die eben im Sande verlaufene Google Wave könnte ebenso wieder auferstehen, und Online Games könnten schneller, aber schlanker werden. Denn der Browser muss für die Aktualisierung nicht ständig den Server befragen, ob es neue Daten gibt: Sobald diese da sind, kann der Server diese dem Client nachsenden.

Das ist eine ganz andere Art HTTP, als wir sie bisher kennen, aber es ist eine coole und smarte Art. Ich habe mal für einen Automobilkonzern in einem Software-Projekt gearbeitet, wo es um eine Dokumentation von Fahrzeugstrukturen ging. Durch die Tiefe der Strukturen (Module, Stücklisten, Assemblys) konnte praktisch ständig mit einer Änderung gerechnet werden. Hier hätte die Software auf Basis eines Web-Clients wohl nur noch gepingt und geflackert. Mit einem PUSH-Modus wäre ein Web-Client als Implementationsplattform viel attraktiver gewesen (als es dieses komische Enterprise Java anscheinend war :-)), und man hätte viele geniale und interaktive Dinge damit machen können.

HTML/HTTP als Entwicklungsplattform

Neben diesem Aspekt gewinnt HTML/HTTP als Implementationsplattform noch an einer anderen Stelle gegenüber “herkömmlichen” Widget-Sets an Charme: Die Standardisierung ist hier etwas ganz einzigartiges. Es gibt für kein Widget-Set der Welt eine internationale Norm: Weder für GTK+, noch für Qt, MFC oder ein anderes Framework. HTML als grafische Benutzer-Schnittstelle ist dabei nicht nur menschenlesbar (und damit im Fehlerfall vom Benutzer debugfähig und interpretierbar), es ist zum anderen auch komplett plattform-neutral, portabel und durch ein unabhängiges Gremium standardisiert.

Man kann also die Rendering Software (den Browser) ebenso wechseln wie die Maschine, dessen OS, Standort oder IP.  Ebenso lassen sich durch die flexible Architektur Inhalte für verschiedene Geräte unterschiedlich aufbereiten und sogar während der Benutzer-Sitzung anders implementieren, ohne dass die Software (was in diesem Fall eine Session wäre), neu gestartet werden muss. Insofern muss ich mal eine ganz dicke Lanze für HTML/HTTP für die Applikationsentwicklung brechen.

Rapid Prototyping, Internationalisierung et cetera – all inclusive

Ebenso unterstützt HTML/HTTP das Design-Prinzip Rapid Prototyping, und für verschiedene Layer wie Persistenz-Schicht, Models, Controller oder Views einer klassischen Programmierersicht gibt es diverse Hilfsmittel. Je nach dem, wie man arbeiten möchte, kann man von den Models automatisch Views und Persistenzen erzeugen lassen, wie auch andersherum. Mit Java, ASP, PHP oder Perl (und sogar C++) stehen dem Entwickler diverse Sprachen zur Verfügung, während dies für den Benutzer absolut transparent bleibt. Man könnte sogar einige Module in Perl, andere in Java oder ASP umsetzen. Neben einem Mini-System lässt sich die Applikation dann a) super-easy “deployen” – dieser Schritt entfiele ja fast – aber auch ebensogut horizontal skalieren, wenn die Benutzerzahl ansteigt.

Die Internationalisierung von Applikationen gestaltet sich besonders einfach, wobei der Browser mit Accept-Headern als Mittler zwischen Benutzer und dessen Sprachauswahl dient. Diverse andere Vorzüge, die mir dazu noch einfallen (Trennung von HTML, CSS und Javscript, der Rechner müllt nicht mit der Benutzer-Konfig zu, man braucht keine Installation, zentralisierte Datenspeicherung, etc.) lassen HTML/HTTP gegenüber anderen GUI-Frameworks immer öfter den Vorzug geben. Und schließlich kommen nun noch Web-Sockets um die Ecke und lassen das HTTP-Protokoll noch einmal kräftig zulegen.

Meiner Meinung nach läuten die Glocken ganz, ganz deutlich: Wer interaktive Applikationen schreibt, sollte ganz offensichtlich eine Online-Implementierung abwägen. Ich freue mich jetzt schon auf diverse neue Spielwiesen, die dabei entstehen werden. 🙂