20.4.05
Ajax: Nix zum Saubermachen und nix aus Amsterdam
Aber eine sehr interessante und wahrscheinlich zukunftstr�chtige Technik f�r moderne Webapplikationen. Es ist keine neue Idee, aber jemand hat sie ausformuliert und ihr einen Namen zum "dr�ber reden" gegeben.
Erreicht werden soll eine striktere Trennung von Interface und Programmlogik f�r Webanwendungen, damit die Performance durch st�ndiges, wiederholtes Laden der Oberfl�che nicht leidet. In dem notwendige Daten in einem unsichtbaren IFrame gespeichert werden, kann der JavaScript-Teil die Steuerung der Anwendung �bernehmen. Nur wenn eine Interaktion mit dem Server notwendig ist, wird dieser per asynchronem Aufruf nach neuen Daten gefragt oder um Mithilfe gebeten. Dadurch ist ein deutlicher Gexchwindigkeitsgewinn zu erzielen, den man bespielsweise bei Gmail schon heute beobachten kann.
Sp�testens wenn man soweit gelesen hat, sollte man sich den Originalartikel durchlesen, denn mehr Zusammenfassung gibt es von mir nicht.
Der Haken an der Sache ist nat�rlich zum einen die M�glichkeit f�r den Client, in dem Code zu pfuschen. Es m�ssen also zus�tzliche Manipulationsm�glichkeiten bei der Entwicklung ber�cksichtigt werden. Zum Zweiten gibt es nat�rlich Clients, die aus gutem Grund JavaScript deaktiviert haben. F�r diese m�sste zus�tzlich ein zweites alternatives Frontend zur Verf�gung gestellt werden. Zum Dritten m�ssen jetzt Programmierer nicht mehr nur PHP, HTML und CSS beherrschen, sondern sich auch noch mit den Besonderheiten von JavaScript umzugehen wissen.
In dieser Technologie stecken sicherlich gro�e bis sehr gro�e M�glichkeiten und ich werde auch in Zukunft dar�ber nachdenken, diese zu nutzen - auch wenn ich noch keine Ahnung habe wie es funktioniert. Ein bisschen erinnert mich das ganze daran, eine GUI manuell im Quelltext zu schreiben, inklusive aller Events und Abh�ngigkeiten. Es ist ein heiden Aufwand, den hinterher keiner sieht. Und auch wenn meine Arbeit um so besser ist, je weniger man davon sieht, so ist es doch irgendwo deprimierend.
Nachtrag: Weiterf�hrende Literatur findet sich bei Einfach f�r alle.
Das ist echt interessant... Bei "Google Suggest" finde ich allerdings überhaupt nichts im Code, was auf die Funktionsweise schließen lässt. Sieht mir mal wieder nach typischem Google-Rezept aus: Funktioniert gut und hat daher keinen zu interessieren, wie eigentlich -- à la PageRank.
Die Nachteile sind natürlich nicht zu übersehen. Was mich jedoch am meisten stört, ist die Gegenüberstellung von Web- und Desktop-Applikationen. Da gibt es m.E. nämlich keinen so großen Unterschied: Mittlerweile ist jede Anwendung irgendwie netzwerkfähig (außer vielleicht ein gut konfigurierter IE), und asynchrone Anfragen an einen Server kann nicht nur ein Browser stellen...
So, nun habe ich mir den Artikel auch zu Gemüte geführt und mir fällt eines dabei auf: Das Ziel ist es ja, eingängige Web Applikationen zu schreiben mit einer schicken Oberfläche und einem Verhalten wie eine Desktop GUI. Doch ist das nicht irgendwo der falsche Ansatz?
Wenn ich eine Web Applikation schreibe, weiß ich worauf ich mich einlasse. Da kann ich mit dem Request / Response Verhalten leben. Diese Technologie / Pattern wird sich nur durchsetzen, wenn es ein Framework gibt, dass es gut und einfach benutzbar macht.
Ist dies nicht der Fall, bleibe ich für schicke Oberflächen bei SOAP in Verbindung mit einer Desktop Sprache oder schlichtem PHP/XHTML/CSS.