Die AJAX-Technologie spaltete um das Jahr 2005 die Web-Welt: "Revolution" meinten die einen, "Hype" sagten die anderen zu der Kombination aus asynchronem JavaScript und XML. Mittlerweile ist AJAX voll etabliert und die Basis fast aller modernen Webseiten, die interaktiv mit dem Anwender agieren. Doch worum geht es eigentlich genau?

AJAX steht für 'Asynchrones JavaScript und XML' - und ermöglicht Webapplikationen wie die neue Version von Google, die so schnell sind, dass sie mit ihren Anwendern nahezu in Echtzeit interagieren können. Obwohl immer wieder Daten mit dem Webserver ausgetauscht werden. Denn mit AJAX werden bei einer Anfrage durch die Nutzer einer Webseite nur die gerade benötigten Teile der Seite nachgeladen, statt sie komplett neu zu laden. So verkürzen sich Lade- und Wartezeiten dramatisch. Das ist besonders für Webanwendungen entscheidend, für die sehr viele Daten dynamisch zur Verfügung stehen müssen. Und das war vor dem Auftreten von AJAX nicht - oder nur mit viel Aufwand - möglich.

Der eigentliche AJAX-Kick für das WWW ist also "Speed": Lange Wartezeiten bei einfachen Änderungen der Webseite gehören der Vergangenheit an, seit sich AJAX durchgesetzt hat.

Die Kerntechniken von AJAX

Die Kerntechniken von AJAX sind dabei nicht neu: HTML beziehungsweise XHTML, JavaScript, Stylesheets, JSON, XML sowie eine im Grunde beliebige Programmiertechnik auf dem Server.

HTML beziehungsweise XHTML, JavaScript und Stylesheets firmieren dabei zusammen als eine Technik mit Namen DHTML. DHTML steht für dynamisches HTML. Der Begriff ist jedoch nicht standardisiert und verschiedene Leute verstehen darunter teilweise unterschiedliche Dinge. In jedem Fall geht es aber darum, eine Webseite zu verändern nachdem sie bereits in den Browser geladen wurde. Als Technik für Stylesheets werden im Web fast ausschließlich die so genannten Cascading Stylesheets oder kurz CSS verwendet.

Das 'X' in AJAX steht für XML. Dieses Datenformat gestattet den Austausch von Informationen, die über den Text hinausgehende Metainformationen beinhalten. Allerdings kann der Datenaustausch zwischen Server und Client auch andere Datenformate nutzen. So können beispielsweise reine Textinformationen, HTML- Fragmente oder andere Klartexte verwendet werden. XML und JSON bieten jedoch die am weitesten gehenden Möglichkeiten.

Viele so genannte Experten kritisierten von Anfang an, dass AJAX im Grunde nur Technologien beschreibt, die es bereits seit geraumer Zeit im Web gibt. HTML gibt es bereits seit 1990, aber auch JavaScript, Stylesheets und XML sind seit Mitte der neunziger Jahre verfügbar. Sogar die asynchrone Nachforderung von Daten, die erst später in ein Dokument integriert werden sollen, gibt es bereits seit ungefähr 1998.

Allgemein wurde das Verfahren zur asynchronen Nachforderung von Daten bis vor kurzem mit dem Begriff XMLHttpRequest beschrieben. Diese Technik geht auf das "Outlook Web Access"-Team von Microsoft zurück und wurde zu der Zeit bereits in den Microsoft-Exchange-Server und den Internet Explorer integriert. Obwohl später weitere isolierte Anwendungen folgten, konnte sich diese Technologie nicht flächendeckend durchsetzen. Erst mit dem Begriff AJAX, den ein Mitarbeiter der Agentur Adaptive Path mit Namen Jesse James Garrett bekannt gemacht hatte, wurde diese Technologie populärer. Und vor allen Projekte von Google wie "Google Groups", "Google Maps" und "Google Suggest" trugen im Jahr 2005 zur explosionsartigen Verbreitung des Begriffs bei.

Das Argument, dass AJAX im Grunde nur kalter Kaffee bei seinem Auftreten war, warjedenfalls nicht zwingend negativ. Genauso gut kann man es umgekehrt sehen: AJAX erforderte keine neue Technologie und konnte sich damit sehr einfach und schnell in das bestehende World Wide Web integrieren. Wahrscheinlich ist die Verbindung bekannter Techniken tatsächlich auch der Hauptfaktor für den rasanten Durchbruch von AJAX gewesen. Im Web setzt sich offensichtlich nur das durch, was schon einfach ist und eine gewisse Zeit reift.

Unter dem im Schlagwort AJAX formierte sich ein Standard, auf den sich in kürzester Zeit alle Beteiligten der Entwicklungen rund um das World Wide Web einigten. Und mittlerweile ist gerade mit HTML5 im Web eine Richtung vorgegeben, die AJAX immer mehr den Rücken stärkt. Man darf sich nicht täuschen, dass AJAX aus der öffentlichen Wahrnehmung etwas verschwunden ist. AJAX ist einfach selbstverständlich.

Die Ausgangssituation: Client, Server und interaktive Web-Applikationen

Um die immense Bedeutung von AJAX für die Zukunft des Webs zu verstehen, muss man sich nur die Arbeitsweisen und vor allem die Probleme der konventionellen Webprogrammierungvor Augen führen. Dann sieht man schnell, wie AJAX hilft, diese Probleme zu lösen.

Bereits das WWW war seinerzeit ein riesiger Fortschritt, es machte aus dem bis dahin rein textbasierten Internet mit isolierten Daten eine multimediale Welt. In WWW ließen sich Inhalte miteinander verknüpfen und optisch interessant aufbereiten. Damit wurde auch für technisch nicht versierte Anwendern die Möglichkeit geschaffen, in einem weltweiten Netzwerk auf Informationen zuzugreifen.

Protokoll-Fragen: TCP/IP, HTTP und die Verbindung

Die technische Basis des WWW ist aber die gleiche wie die des Internets. Der gesamte Datenaustausch basiert auf TCP/IP. Dies steht für 'Transmission Control Protocol / Internet Protocol' und bezeichnet eine Paketvermittlung bei der Datenübertragung. Die Daten zwischen den Kommunikationspartnern werden in kleine Dateneinheiten zerlegt und diese unabhängig voneinander vom Sender zum Empfänger geschickt. Zwischen den Kommunikationspartnern gibt es keine permanente Verbindung.

Die auf TCP/IP aufsetzenden Dienstprotokolle des Internets realisieren zwar teilweise eine virtuelle Verbindung, aber das ist nicht bei allen Dienstprotokollen des Internets der Fall. Insbesondere das Protokoll des WWW - HTTP - ist ein verbindungs- oder zustandsloses Protokoll. Während der Kommunikation zwischen einem Webserver und einen Browser wird also keine Verbindung aufrechterhalten. Wenn ein Browser von einem Server eine Webseite anfordert, und in einem zweiten Schritt der gleiche Browser eine weitere Seite von diesem Server anfordert, kann der Webserver nicht erkennen, dass die Anforderung von dem gleichen Client kam.

Sie kennen aus Ihrer Erfahrung im World Wide Web natürlich Situationen, in denen der Webserver erkennen kann, ob ein Client bereits vorher Seiten angefordert hat. Dies ist in allen Situationen der Fall, in denen man sich legitimieren muss, um in einem geschlossenen Bereich Webseiten zu sehen. Dies wird aber nicht über TCP/IP beziehungsweise HTTP gewährleistet, sondern mit Anwendungstechniken, die darauf aufsetzen, zum Beispiel Cookies.

Anfordern & Versenden von Daten

In der Anfangsphase des Webs war ein Anfordern einer Webseite durch einen Client und deren Darstellung nach Erhalt der Antwort vollkommen ausreichend. Aber bereits nach einigen Jahren genügten vielen Leuten rein statische Webseiten nicht mehr. Die mangelnden Möglichkeiten der Interaktion mit einem Betrachter einer Webseite führten dazu, dass Technologien wie JavaScript, Java-Applets, VBScript, oder diverse weitere Techniken entstanden. Diese Technologien werden allesamt in Client ausgeführt. So genannte clientseitige Programmierung ist als erste Optimierung des Webs zu verstehen.

Allerdings kann clientseitige Programmierung selbstverständlich nicht alle Aufgaben des Webs übernehmen. Das Versenden neuer Daten ist natürlich immer noch Aufgabe des Servers. Ebenso werden sicherheitsrelevante Dinge wie die Überprüfung von Zugangsdaten nicht auf den Client verlagert, wenn man nicht ein großes Risiko eingehen will.

Clientseitige Programmierung hat aber darüber hinaus noch weitere Nachteile. Es muss gewährleistet sein, dass die clientseitige Technologie im Rahmen einer Webseite beim Client auch unterstützt wird. Und aufgrund unterschiedlichster Gegebenheiten wurde etwa ab dem Jahr 2000 die clientseitige Programmierung im Web mehr und mehr zurückgedrängt. Zum Teil waren es Sicherheitslücken in clientseitigen Programmiertechniken, zum Teil waren es marktpolitische Überlegungen. Und zum Teil hatten Anwender bestimmte Techniken einfach nicht in dem Client installiert. Dies betraf vor allem proprietäre Standards.

Die Probleme bei clientseitiger Programmierung bewirkten etwa ab dem Jahr 2000 die zunehmende Rückverlagerung von Aktivität auf den Webserver. Mittlerweile jedoch hat sich die Situation normalisiert. Bei komplexeren Webapplikationen ist inzwischen weder das eine Extrem (möglichst viel Aktivität bereits auf dem Client auszuführen) noch das andere Extrem (die komplette Verlagerung auf den Webserver) mehr üblich. Die Aufgaben werden statt dessen mehr und mehr so verteilt, wie sie sinnvoller Weise erledigt werden sollten. Was im Client sinnvoll gemacht werden kann, wird bei allen populären Webseiten heutzutage dort erledigt. Und was sinnvoller Weise auf dem Server zu machen ist, macht man dort, mittels einer geeigneten Programmiertechnik. Insbesondere das Open Source-Projekt PHP hat viel zu der steigenden Popularität von serverseitiger Programmierung beigetragen. In Verbindung mit dem Webserver Apache, der ebenfalls Open Source ist, hat sich der Begriff 'LAMP' beziehungsweise 'WAMP' etabliert und viele Anwender programmieren mittlerweile auch auf den Server.

Wenn Sie sich heute populäre Webseiten ansehen, kommt keine einzige dieser angesagten Seiten ohne JavaScript oder Stylesheets daher. Entsprechend verschwindet auch mehr und mehr die Empfehlung, dass Anwender JavaScript im Browser deaktivieren sollen. Kaum ein Anwender möchte auf den Nutzen populärer Webangebote wie Google, Amazon, eBay, Wikipedia oder ähnlichen Smashern verzichten. Allerdings haben die Probleme der clientseitigen Programmierung in der Vergangenheit dazu geführt, dass es als einzige clientseitige Programmiertechnik im Web heutzutage nur noch JavaScript gibt.

Wie kommt AJAX ins Spiel?

Wenn man heutzutage bei jeder aufwändigeren Webapplikation eine vernünftige Aufteilung zwischen der Arbeit auf dem Webserver und dem Ausführen von Programmierung auf dem Client sieht, wozu braucht man dann noch AJAX?

Nun, das Problem von HTTP ist weder durch clientseitige Programmierung noch durch Programmierung auf Serverseite zu lösen: die Notwendigkeit, bei der Reaktion auf eine Anfrage durch einen Webbrowser immer eine vollständige Webseite als Antwort zu senden. Dies berührt diese Arbeitsteilung überhaupt nicht.

Überlegen Sie als Beispiel ein Webformular, in dem der Anwender eine Postleitzahl eingeben soll. Je nach eingegebener Postleitzahl soll dem Anwender in der Webseite eine ergänzende Information angezeigt werden, und zwar der Name der Stadt, die zu der Postleitzahl passt. Sie können nun bereits beim Anfordern des Webformulars auf Vorrat alle zusammengehörenden Postleitzahlen und Städte zum Client senden und diese Information für JavaScript vorhalten. Dann können Sie aufgrund der Auswahl des Anwenders diese Information mit DHTML-Techniken in der Webseite anzeigen.

Es ist aber offensichtlich, dass so zuerst viele überflüssige Daten zum Client geschickt werden müssen, die später niemals verwendet werden. Das Verschicken von Daten auf Vorrat ist also ineffektiv. Vor allem, wenn das in mehreren Situationen für eine Webseite notwendig ist oder allgemein große Datenmengen betroffen sind. Stellen sich vor, Google sollte seinen gesamten Datenbestand zum Client schicken, um bei Bedarf ergänzende Informationen in der Webseite anzuzeigen. Das ist vollkommen illusorisch.

Hier betritt AJAX die Bühne! Mit AJAX hat man eine zunehmend standardisierte Vorgehensweise zu Verfügung, wie man ohne Vorratshaltung von Daten auskommt und dennoch eine Reaktion der Webapplikation nahezu in Echtzeit gewährleisten kann. Und dies, obwohl neue Daten vom Webserver angefordert werden. Statt der Anforderung einer vollständigen Webseite wird eine AJAX-Datenanfrage dazu führen, dass nur die neuen Daten vom Webserver geschickt und diese dann in die Webseite eingebaut werden, die bereits im Browser geladen ist. Es ist offensichtlich, dass so eine Vorgehensweise die versendete Datenmenge erheblich reduziert und eine Webapplikation gigantisch beschleunigen kann.