Samstag, 9. Juni 2007

Web-Anwendungen versus Web-Anwendungs-Frameworks

Das neue Java Spektrum Juni/Juli 07 hat "Frameworks für Web-Anwendungen" als Schwerpunktthema. Wenn ich mir die Beiträge so durchlese, werde ich den Verdacht nicht los, dass sich hier die Frameworks selbst in den Mittelpunkt stellen. Die Web-Anwendung dient dabei nur noch als Strohmann, als Sinngeber für die Framework-Entwickler: Schaut her, mit unserem Framework wird die Entwicklung dieser Web-Anwendungen vereinfacht.

Aber wird sie das wirklich? Wo die Vorgehensweise einmal in allen Details vorgeführt wird, wie in dem sehr gut nachvollziehbaren Artikel von Klaus P. Berg über das Google Web Toolkit, hat man eher den gegenteiligen Eindruck. Eine steile Lernkurve scheint nötig zu sein, der Artikel verheisst lange Nächte des Bastelns. Man wird sich auf eine neue Technologie einlassen, die sicher interessant kennenzulernen ist. Man wird im Endeffekt eine Web-Anwendung erhalten, die man mit konventionellen Mitteln mit weniger Aufwand ebenfalls hinbekommen hätte. Hier fände ich Ockhhams Rasiermesser einmal angebracht! Der Weg, auf dem man mit weniger Mitteln zum selben Ziel kommt, ist der vorzuziehende. Es sind ja meine Nächte, die ich mir um die Ohren hauen muss! :-)

Darüberhinaus habe ich ein tief sitzendes Misstrauen gegen alle Arten von HTML-Code-Generierung. Möglicherweise ist dies in einem frühen FrontPage-Trauma begründet, als ich erleben musste, wie mir mein ganzer schöner HTML-Code durch irgendwelche von der Maschine hingeschmierten Konstrukte überschrieben wurde. Aber auch mit anderen Tools wie DreamWeaver habe ich Ähnliches erlebt, bis ich vor vielen Jahren zu Plain Text Editoren für alle meine HTML-Seiten überging (und übrigens auch für meine Java-Programme: ich brauche keine "Builder"-Monstren, sondern schreibe mir je Projekt ein kleines Script mit den nötigen Anweisungen zum Compilieren). Klaus P. Berg berichtet, dass auch das Google Web Toolkit HTML-Code generiert - wie alle "Top of the Art" Frameworks für Web-Anwendungen, aber gnädigerweise eine Art "Native Interface" vorsieht, damit man doch noch hier und dort ein paar HTML-Tags einbauen darf.

Den Vergleich eines solchen HTML-Exits mit Suns Java Native Interface (JNI) finde ich allerdings deplaziert. Das Java Native Interface bietet Absprünge für maschinenspezifischen Code. Aber HTML, CSS und JavaScript sind nicht maschinenspezifisch. Für alle drei Sprachen gibt es Standards; wenn man diese einhält, hat man mit den Browsern dieser Welt keine grösseren Probleme. Es ist nicht korrekt, HTML, CSS und JavaScript als "Low Level"-Konstrukte hinzustellen, auf die man von seiner Framework-Warte hinabblicken kann.

An Stelle derartiger Frameworks wäre eine umgekehrte Perspektive die richtige, wenn man wirklich die Arbeit der Web-Entwickler unterstützen möchte: Der Web-Entwickler entwirft die Views, die Steuerung und die Logik seiner Anwendungen. Für Unterstützung bei der Entwicklung der Views - also der HTML-Fragmente, die zu einer vollständigen Webseite zusammengesetzt werden, ist jeder Web-Entwickler dankbar. Dazu gehören Tag Libraries, um den HTML-Code einzelner graphischer Elemente wie Buttons oder Inputfelder übergreifend und einheitlich herzustellen. Dazu gehören auch schlanke JavaScript-Bibliotheken wie Sarissa oder Prototype, die ihm die Arbeit abnehmen, browserübergreifend Ajax-Requests zu versenden oder Seiteninhalte dynamisch zu verändern. Ein HTML-Validator wie Tidy ist unverzichtbar. Letztlich behält der Web-Entwickler aber die Kontrolle über den in die Welt gesandten HTML-Code. Wenn die Anwendungslogik unter Einhaltung des Model-View-Controller Archtitekturmusters angebunden ist, ergibt sich insgesamt eine saubere Web-Anwendung, deren Wartung oder Weiterentwicklung ich jederzeit gern von einem Kollegen übernehmen würde!

Keine Kommentare :