WEB 2.0 Ajax

Mehr Spaß mit AJAX?!

Nach den Hypes der letzten Jahre hat sich die Euphorie in Entwicklung und Nutzung des WWW gelegt und man ist zur Normalität übergegangen. Flash, Datenbanken, XML, Barrierefreiheit, CMS und CSS, alles Begriffe, die in den vergangenen Jahren geprägt, gepusht und auch überstrapaziert wurden, sind zur Normalität in einem Großteil der Webprojekte geworden. Nach den Versuchen und Experimenten mit allen möglichen Technologien ging der Trend in den letzten Jahren zu klar strukturierten, im Frontend aufgeräumten, templatebasierten Sites, die in der Benutzung für wenig Überraschung sorgten. Der Informationsgehalt und die Aktualität sind hoch, die Designqualität solide. Das Handling gelernt und wenig spannend. Interaktivität, Flash-Sites einmal ausgenommen, beschränkte sich auf JavaScript-Rollover-Effekte und CSS-Menüs.

Nun steht Änderung ins Haus, denn seit Anfang des Jahres soll eine Bündelung bestehender Technologien unter neuem Namen für mehr Spaß und Abwechslung auf dem Webclient(Browser) sorgen: Ajax.
Ajax ist keine neue Programmiersprache, kein bisher unbekanntes Plug-In, kein frisch vom W3C empfohlener Webstandard und auch kein neu implementiertes Browserfeature. Es handelt sich vielmehr um eine geschaffene Marke, hinter der sich alteingesessene Technologien verbergen. Dazu später mehr.
Der Begriff Ajax steht für “Asynchronous Javascript and XML” und beschreibt grundsätzlich erst einmal eine Technik, die den Datenaustausch zwischen einem Webserver und einem Webclient ermöglicht, ohne dass immer eine komplette Seite neu geladen werden muss. Dies geschieht, wie am Namen erkennbar, mittels der clientseitigen Scriptsprache JavaScript und vorrangig XML als Datenformat.
Einen Erfinder oder Entwickler von Ajax gibt es nicht, zumindest nicht nachvollziehbar. Die Bezeichnung tauchte erstmals in einem Essay von Jesse James Garrett auf, das er auf der Site seiner Webagentur “Adaptive Path” im Februar 2005 veröffentlichte. Zu diesem Zeitpunkt hatte Google bereits seine Tools “Google Suggest” und “Google Maps”, auf die Garrett sich auch bezieht, ohne die Bezeichnung Ajax entwickelt.
Ob er mit dem Schaffen einer neuen Marke nur für Aufmerksamkeit für seine Agentur sorgen wollte oder einfach einen Namen für die Beschreibung für etwas bereits Bestehendes suchte, ist nicht klar. So gilt er als inoffizieller Erfinder des Brandes und sein Text wird in wahrscheinlich jedem Ajax-Artikel zitiert.

Vom Get/Put über Flash zu Ajax
Die Übertragung von Inhalten auf herkömmlichen Websites geschieht nach dem alten Client-Server-Prinzip. Ein Server stellt Daten (HTML-Seiten, Bilder, etc.) zur Verfügung, die ein Webclient herunterlädt und lokal auf dem Rechner des Benutzers anzeigt. Dabei kann man kleinere Funktionen, die meist nur das Interface grafisch aufpeppen, per Javascript lokal auf dem Client ablaufen lassen. Mehr aber auch nicht.

Soll eine Interaktion, also ein bi-direktionaler Datenaustausch mit dem Server erfolgen, muss der Benutzer diesen z.B. durch das Drücken eines Buttons auf der Webseite auslösen. In ein HTML-Formular eingegebene Daten werden dabei per Get- oder Put-Methode an den Server geschickt, dort verarbeitet und der Benutzer bekommt eine Antwort in Form einer neuen HTML-Seite. Jede noch so kleine Anfrage an den Server wurde also mit dem Herunterladen einer kompletten HTML-Seite beantwortet. Das war bzw. ist im Netz so gelernt und akzeptiert, nur ist man von seinen Desktopprogrammen anderes gewohnt und der Wunsch nach Abbildung von, zumindest einigen, Desktopfunktionen war schon immer vorhanden.

Als Flash aufkam, war die Hoffnung groß. Bewegung, Drag and Drop und auch das dynamische Nachladen von Inhalten war möglich. Durchsetzen konnte sich das Format aber gerade mal bei Sites mit gehobenem grafischen/interaktiven Anspruch. Dateigröße, zusätzlicher Entwicklungsaufwand, die Voraussetzung eines installierten Plug-Ins, die immer mehr aufkommende Notwendigkeit von der Erstellung barrierefreier Websites und vor allem die aufwändige inhaltliche Pflege waren und sind nach wie vor ein Hemmnis, das die Verbreitung von Flashsites stagnieren lässt.

Der Fokus der Browser- und damit Webentwickler richtete sich anschließend zunehmend auf Darstellung und Präsentation von Webapplikationen auf dem Client. Durch die Weiterentwicklung des CSS-Standards und dessen Implementierung in die Browser ist effiziente, zukunftsorientierte und flexible Formatierung der Inhalte kein Problem mehr.
Die Weiterentwicklung von JavaScript verlief im Stillen. Die zunehmenden Möglichkeiten, Objekte und damit Inhalte auf dem Client zu be- und verarbeiten, wurden über lange Zeit ignoriert oder nur in kleinem Rahmen genutzt. JavaScript hatte bzw. hat ein schlechtes Image. Meldungen über Sicherheitslücken, die sich durch Scripte ausnutzen lassen (hier tat und tut sich der Internet Explorer unter Windows immer wieder mit Negativmeldungen hervor, aber auch Firefox war verwundbar), führen zu Verunsicherungen bei den Usern. JavaScript ist somit oft deaktiviert. Webentwickler müssen aus diesem Grund immer eine “scriptlose” Benutzung garantieren, Scripte wurden allenfalls als Goodies entwickelt.

Ajax schickt sich jetzt an, dieses Negativbild zu relativieren. Die Aktivierung und damit Nutzung von JavaScript ist Grundvoraussetzung aller Ajax-Anwendungen. Der Mehrwert für den User kann immens sein, nur muss die JavaScript-Implementierung des Browsers sicher und in der Nutzung für den User unproblematisch sein.

Alter Wein …
Wie oben bereits erwähnt ist Ajax keine eigenständige Technolgie oder ein (neues) Produkt. Es bildet einen Zusammenschluss aus bereits etablierten Techniken, die von den entsprechenden Webclients unterstützt werden müssen. Eine Ajax-Anwendung beinhaltet die folgenden Webtechnologien:
- HTML und CSS für die Darstellung der Inhalte
- Document Object Model, das eine Programmierschnittstelle ist, die den Zugriff auf die Objekte (Layer, Bilder, etc.) einer Website erlaubt
- XML und XSLT für Datenaustausch zwischen Client und Server
- JavaScript als Schnittstelle aller Komponenten
- das XMLHttpRequest-Objekt

Letzteres ist das technologische Kernstück der Anwendung. Das XMLHttpRequest-Objekt erlaubt es dem Client, Daten mit dem Server auszutauschen, ohne dass die aktuelle Seite neu geladen werden muss. Die Datenübertragung findet dabei im Hintergrund statt. Der Benutzer kann in der Zeit weiter die Anwendung nutzen und bekommt dann, je nach Dauer der Datenverarbeitung auf dem Server und seiner Internetanbindung, ein entsprechendes Feedback.
Dazu ein erstes einfaches Beispiel von Google Suggest: Tippt der User ein Wort in das Suchfeld, schickt der Client dieses im Hintergrund an den Server. Auf dem Server werden ähnliche Worte gesucht und die Ergebnisse mit der entsprechenden Trefferanzahl als XML-Daten zum Client zurückgeschickt. JavaScript-Funktionen sorgen auf dem Client für die Verarbeitung und die Darstellung der Ergebnisse in Form eines Pulldowns im Browser.

Das XMLHttpRequest-Objekt wurde ursprünglich von Microsoft als proprietäres ActiveX-Objekt für den Internet Explorer entwickelt. Andere Browserentwickler erkannten die Vorteile dieser Technik und integrierten sie auch in ihre Webclients. Inzwischen unterstützen alle wichtigen aktuellen Browser (Firefox, Mozilla, Camino, Safari, Opera, etc.) dieses Objekt zum Datenaustausch. Da es sich aber nicht um einen (W3C) Standard handelt, gibt es, wie oft in solchen Fällen, das Problem der unterschiedlichen Implementierung und damit einer nicht einheitlichen Nutzung der Funktionen. Die Unterschiede zwischen Internet Explorer und “Nicht Internet Explorer”-Browsern sind im Falle des XMLHttpRequest-Objekts nicht so gravierend. Aber die Abweichungen müssen bedacht und entwickelt werden.

Neben den Funktionalitäten auf der Clientseite sind natürlich auch Programme oder Scripte auf dem Server notwendig, welche die ankommenden Anfragen aufnehmen, verarbeiten und die entsprechenden Daten an den Client zurückschicken. Hierzu ist im Prinzip jede serverseitige (Script-)Sprache geeignet. In der Regel wird es sich um PHP- oder Perl-Scripte oder JSP handeln. Als Rückgabemedium ist jedes strukturierte Datenformat geeignet. In einem Großteil der Anwendungen wird es sich um XML handeln, aber auch formatierte HTML-Daten oder auch ASCII-Texte wären geeignet.

Vorteile
Die teilweise oder vollständige Nutzung oben genannter Technologien in einer Ajax-Anwendung haben ihren größten Vorteil darin, dass eine Änderung oder Abfrage von Daten, also Objekten einer HTML-Seite, nicht mit einem kompletten Reload dieser einhergehen muss. Interaktion ist somit direkter und schneller möglich, da nur relevante Inhalte neu geladen werden müssen. Redundanz durch das Neuladen unveränderter Inhalte und damit Zeitverlust bei Laden und Anzeigen der Daten wird vermieden. Das betrifft die reinen clientseitigen Funktionen (z.B. Drag and Drop bei WordPress) und noch mehr Applikationen in Kombinationen mit Serveranfragen und -rückgaben (z.B. Google Suggest).
Die Manipulationsmöglichkeit des DOM (Document Object Model), also aller auf einer Seite befindlichen Elemente des Browsers durch eine Ajax-Anwendung, bietet Entwicklern die Möglichkeit, Funktionalitäten ähnlich einer Desktopanwendung zu erstellen. Dadurch, dass sich der Großteil der Anwendungslogik auf dem Client befindet und dort abgearbeitet wird und Datenflüsse zum und vom Server im Hintergrund abgewickelt werden, entsteht für den Benutzer der Eindruck, ein herkömmliches Windows-, Mac OS- oder Unix-Programm zu benutzen. Als Beispiel seien hier RichText Editoren genannt, die es, vorrangig in Web Content Management Systemen, Redakteuren ermöglichen, Texte wie in einem Officeprogramm zu formatieren.
Ein grundsätzlicher Vorteil ist es außerdem, dass alle Funktionalitäten mit den als “Bordmittel” der Browser zu Verfügung stehenden Technologien umgesetzt werden können. Das zusätzliche Installieren eines Plug-Ins ist nicht erforderlich.

Nachteile
Der Vorteil von Ajax-Anwendungen, die fast vollständige Abarbeitung der Programmfunktionalitäten durch den Client ist gleichzeitig ein großer Nachteil. JavaScript ist zwingende Voraussetzung. Sollte ein Benutzer z.B. aus oben genannten Sicherheitsgründen die Benutzung der Scriptsprache deaktiviert haben oder unterstützt der Client kein JavaScript (z.B. ein PDA- oder Handybrowser), ist eine Website mit Ajax-Funktionalitäten nicht nutzbar. Im besten Fall bekommt der User noch einen freundlichen Hinweis, dass eine Nutzung der Seite ohne JavaScript nicht möglich ist, im schlechtesten sieht er nichts oder nur Datenmüll.
Nachteilig kann auch die Entwicklung von komplexen Anwendungen sein, da es für JavaScript keine geeigneten Entwicklungs- und damit Debugging-Umgebungen gibt.
Dazu kommen die unterschiedlichen Implementierungen der Webtechniken in den verschiedenen Browsern. Crossbrowserentwicklung und damit verbundenes aufwändiges Testing ist zwingend notwendig. Ein Ansatz zur Abhilfe ist hier die Entwicklung von Ajax-Frameworks und Librarys, die diese Unterschiede ausgleichen und Grundfunktionalitäten bereits abdecken können.
Zwei weitere große Kritikpunkte zeichnen sich außerdem ab: die Aufhebung der “Zurück”-Button-Funktion und das Nichtvorhandensein einer Bookmarkmöglichkeit eines Zustandes der Seite. Der “Zurück”-Button im Browser kann nur dann zum Einsatz kommen, wenn eine Seite komplett neu angerufen wurde. Änderungen von Eigenschaften oder Zuständen von Seitenelementen werden nicht erfasst. Die Betätigung des Buttons führt damit zum “Verlust” des aktuellen Zustandes der Seite.
Auch können vorgenommene Änderungen an den Elementeigenschaften oder -inhalten einer Seite nicht gebookmarkt werden. Es ist nur möglich, einen Link auf den Zustand der Basisseite (wie beim ursprünglichen Laden) im Browser zu hinterlegen. Zur Lösung dieses Problems gibt es aber erste Ansätze, die z.B. die Speicherung von Elementeigenschaften in Parametern z.B. bei Google Maps ermöglichen.
Und ein letzter Nachteil ist die Unmöglichkeit, Ajax-Programme barrierefrei zu entwickeln. Es wird also in einem großen Teil der Fälle notwendig sein, alternative Darstellungen und Funktionen anzubieten, die den Anforderungen von barrierefreien Webapplikationen entsprechen.

Und weiter?
Durch den großen Entwicklungs- und damit Kostenaufwand, die Abhängigkeit von unterschiedlichster Clientsoftware und deren (aktivierten) Funktionen und die Notwendigkeit, nicht scriptgesteuerte Alternativen anbieten zu müssen, wird es in der nahen Zukunft kein massives Erscheinen von “Ajax-Websites” geben.
Die Technologien eignen sich zur Entwicklung spezieller Websites, die diese exzessiv nutzen werden und mit den damit ausgeschlossenen Benutzern leben können.
Interessant wird es in dem Bereich, wo die Nutzergruppe definiert und bereit oder verpflichtet ist, neuste Clients mit den entsprechenden Techniken zu nutzen, z.B. bei der Nutzung von CMS– oder Blogsoftware.
Ob die Verlagerung von Desktopapplikationensfunktionen auf den Webclient weiter zunimmt, wird sich zeigen. Einzelnen Anwendungen wie Kontakt- und Terminverwaltung über Webapplikationen werden bereits hinreichend genutzt. Eine erste Photoshop-Ajax-Anwendung (nexImage) ist da dann aber doch eher ein Proof-of-Concept.

Keine ähnlichen Posts

Text aus De:Bug 98
Autor: Fabian Fisahn
Ausgabe 98 hier Online via Paypal bestellen.