Ajax (Programmierung)

Ajax [ˈeɪdʒæks] ist ein Apronym für die Wortfolge Asynchronous JavaScript and XML. Es bezeichnet ein Konzept der asynchronen Datenübertragung zwischen einem Server und dem Browser, welches es ermöglicht, dass die HTML-Seite nicht mit jeder HTTP-Anfrage komplett neu geladen werden muss. Das eigentliche Novum besteht in der Tatsache, dass nur gewisse Teile einer HTML-Seite oder auch reine Nutzdaten sukzessiv bei Bedarf nachgeladen werden.

Bei Ajax werden verschiedene bekannte Technologien eingesetzt, um interaktive, Desktop-ähnliche Webanwendungen zu realisieren. Diese vermitteln so den Eindruck, als ob das Problem der zustandslosen Webanwendung behoben wurde.

Eine Ajax-Anwendung basiert auf folgenden Web-Techniken:

• HTML (oder XHTML)
• Document Object Model zur Repräsentation der Daten bzw. Inhalte.
• JavaScript zur Manipulation des Document Object Models und zur dynamischen Darstellung der Inhalte. JavaScript dient gleichzeitig als Schnittstelle zwischen einzelnen Komponenten.
• Das XMLHttpRequest-Objekt, Bestandteil vieler Browser, um Daten auf asynchroner Basis mit dem Webserver austauschen zu können.
• Eine andere Transportmethode ist On-Demand JavaScript^[1], bei der eine JavaScript-Datei per DOM-Manipulation angefordert wird.

Bei der asynchronen Übertragung der Daten haben sich verschiedene Verfahren etabliert:

• REST-ähnliche Verfahren, um Nutzdaten in Textform zu übertragen.
• JSON ist ein auf JavaScript zugeschnittene textbasiertes Format für Daten und Objekte.
• Diverse proprietäre XML Formate.
• SOAP ist das auf XML basierende, standardisierte Austauschformat für Web Services.
• HTML um Fragmente der aktuellen Seite auszutauschen.

Im Zusammenhang mit Ajax-Anwendungen werden auch andere Web-Technologien eingesetzt, die ursächlich aber keinen Zusammenhang mit Ajax haben:

• CSS zur Formatierung einer Webseite.
• XSLT zur Datentransformation.

Von wem die Begriffsschöpfung Ajax ursprünglich stammt, ist nicht mehr eindeutig nachvollziehbar. Sicher ist jedoch, dass den Begriff Jesse James Garrett, ein Mitarbeiter der Agentur Adaptive Path, in seinem Aufsatz Ajax: A New Approach to Web Applications maßgeblich geprägt hat. Grundsätzlich waren die technologischen Grundlagen und die Vorgehensweise aber bereits vorher bekannt und wurden generell mit dem Begriff XMLHttpRequest beschrieben. Wenn man so will, hat Garret also die Marke Ajax erschaffen, um so diverse Software-Technologien unter einem Begriff zu subsumieren.

Die Idee und die damit verbundenen Technologien, welche dem Ajax-Konzept zugrunde liegt, gibt es in vergleichbarer Form schon seit etwa 1998. Die erste Komponente, die es ermöglichte, clientseitig eine HTTP-Anforderung auszulösen, basierte auf einer von Microsoft entwickelten Remote-Scripting-Komponente ^[2]. Später wurde diese Idee durch das Outlook Web Access-Team verfeinert. Diese Komponente ist Teil des Microsoft-Exchange-Servers und wurde auch bald, in Form einer XML-Unterstützung, als Bestandteil des Internet Explorer 4.0 ausgeliefert^[3]. Manche Beobachter stufen Outlook Web Access als ersten erfolgreichen Vertreter des Ajax-Konzepts ein. Dennoch basierten diese sehr frühen Umsetzungen des Konzeptes teilweise noch nicht auf dem XMLHttpRequest-Objekt.

Später folgten Anwendungen wie Oddposts Webmail-Produkt. Im Jahr 2005 war der Begriff Ajax zunehmend durch einige wegweisende Ereignisse in den Medien präsent. Zum einen benutzte Google das asynchrone Kommunikations-Paradigma in einigen bekannten interaktiven Anwendungen wie beispielsweise Google Groups, Google Maps, Google Suggest, Gmail und Google Finance. Der von Garrett verfasste Artikel hat im Ajax-Umfeld inzwischen einen gewissen Bekanntheitsgrad erlangt. Letztlich hat sich die Ajax-Unterstützung der Gecko-Engine in einem Maß entwickelt, welche es ermöglicht, die Ajax-Technologie in vielfältiger Weise einzusetzen.

Neueste Standardisierungsunterfangen des XMLHTTPRequest-Objekts seitens des W3C und die Gründung der Open Ajax Initiative ^[4] lassen erkennen, das die Industrie zukünftig die Ajax-Technologie in ihre Produkte integrieren und somit auf breiter Basis unterstützen wird.

Im Bereich der Standardisierung des Protokolls zwischen Webbrowser und Webserver bei der direkten Ajax-Programmierung findet der Kommunikationsstandard SOAP weite Unterstützung ^[5], da damit die auf einem Server bereits vorhandene, auf Web Services basierende Implementierung, wiederverwendet werden kann.

Datei:Ajax-prozessfluss-traditionell.png

Ajax-Anwendungen erwecken den Eindruck, dass sie gänzlich auf dem Computer des Anwenders ausgeführt werden. Der Prozessfluss einer traditionellen Webanwendung wird hingegen durch die zustandslose Natur des HTTP-Protokolls bestimmt. Das damit unmittelbar verbundene Request-Response-Paradigma führt dazu, dass bei jeder Benutzeraktion eine zugehörige Anfrage (engl. Request) an den Server gerichtet wird. Verzögert sich die erforderliche Antwort (engl. Response) des Servers oder bleibt diese gar aus, so entstehen unweigerlich längeren Wartezeiten oder im schlechtesten Fall Brüche im Ablauf der Anwendung. Das geschilderte Szenario macht es auch für den Benutzer erkenntlich, dass eine traditionelle Webanwendung auf mehrere Bereiche verteilt wurde – ein Umstand, der mit der Ajax-Programmier-Technik transparenter und somit auch fehlertoleranter gestaltet werden soll.

„Jede Benutzeraktion, die für gewöhnlich eine HTTP-Anfrage erzeugen würde, erzeugt nun einen JavaScript-Aufruf, der an die Ajax-Engine delegiert wird [...]“, so beschreibt es Garrett in seinem Essay. „Jede Antwort auf eine Aktion des Nutzers, die keine Verbindung zum Server erfordert, – wie beispielsweise das Validieren von Daten, das Verändern von Daten, welche sich im Speicher befinden, und sogar das Navigieren zwischen einzelnen Elementen der Webseite – all dies kann von der Ajax-Engine bewältigt werden. Benötigt die Ajax-Engine Daten vom Server, um eine bestimmte Aktion erfolgreich durchführen zu können – es kann sich hierbei beispielsweise um das Übertragen von Daten, die verarbeitet werden müssen, um das Nachladen einzelner Bausteine der Benutzeroberfläche oder um das Laden neuer Daten handeln –, führt diese eine asynchrone Anfrage, für gewöhnlich in Form eines XML-Dokuments, an den Server durch. Dabei wurde jedoch die Interaktion des Benutzers mit der Anwendung, wie dies bei gewöhnlichen Webanwendungen der Fall ist, nicht unterbrochen [...]“.

Traditionell übermitteln Webanwendungen Formulare, die zuvor vom Benutzer ausgefüllt wurden, an einen Webserver. Der Webserver antwortet, indem er dem Browser des Nutzers eine, entsprechend der zuvor übermittelten Formulardaten neu generierte, Webseite schickt. Aufgrund der Tatsache, dass der Webserver bei jeder Anfrage seitens des Nutzers eine neue Webseite erzeugen und übermitteln muss, erscheint die Anwendung dem Benutzer insgesamt als träge und wenig intuitiv, vergleicht man diese mit einer gewöhnlichen Desktop-Anwendung.

Ajax-Anwendungen hingegen sind in der Lage, Anfragen an den Server zu schicken, bei denen nur die Daten angefordert werden, die tatsächlich benötigt werden. Für gewöhnlich geschieht dies über den Aufruf eines SOAP-Web-Services oder eines vergleichbaren XML-basierten Web-Service-Dialekts. Der Client, also der Webbrowser, verarbeitet die Antwort des Servers nicht direkt, sondern schleust diese durch den JavaScript-Prozess der Ajax-Engine. Im Ergebnis erhält man so eine Benutzeroberfläche, die sehr viel zügiger auf Benutzereingaben reagiert. Ein Grund für dieses veränderte Verhalten ist die Tatsache, dass wesentlich weniger Daten zwischen Webbrowser und Webserver ausgetauscht werden müssen. Zudem wird die Webserverlast reduziert, da schon viele Verarbeitungsschritte clientseitig getätigt werden können.

Man stelle sich beispielsweise eine Webanwendung zur Verwaltung von Fotografien vor. Möchte der Benutzer einem Foto eine Beschreibung oder einen Titel hinzufügen, so müsste bei einem traditionellen Programmieransatz die gesamte Seite einschließlich der Bilder neu generiert werden. Mit der Ajax-Technologie wird nur der Bereich der Webseite erneuert, der auch verändert wurde. Seiten-Inhalte werden in diesem Zusammenhang über dynamisches HTML aktualisiert. Dieses Beispiel veranschaulicht, wie es innerhalb der Flickr-Anwendung möglich ist, Titel einzelner Bilder zu verändern.

Datei:Ajax-prozessfluss-ajax.png

Da Ajax-Anwendungen dem Client-Server-Architektur-Prinzip entsprechen, ist sowohl innerhalb des Webbrowsers als auch auf dem entsprechenden Server eine Komponente notwendig, die eine Ajax-basierte Kommunikation ermöglicht.

Die Umsetzung innerhalb des Webbrowser erfolgt in den meisten Fällen mit der Hilfe einer umfangreichen Funktionalität auf der Basis von JavaScript und dem XMLHttpRequest-Objekt. Dabei lassen sich zwei Kategorien von Plattformen unterscheiden:

Direkte Ajax-Implementierungen – Diese stellen auf dem Client ein API zur direkten Kommunikation von Daten zur Verfügung. Dazu ist auf dem Server neben der initial abgezeigten Seite ein weiterer Einstiegspunkt zur Übermittlung der Daten zu realisieren.

Indirekte Ajax-Implementierungen – Dabei werden neue HTML-Fragmente vom Server an den Client gesendet, um die vorhande Seite zu ergänzen oder Teile davon zu ersetzen. Meist wird dazu auf dem Server die komplette anzuzeigende Seite neu aufgebaut, aber nur die relevanten Unterschiede zum Client übertragen.

Beide Verfahren haben Vor- und Nachteile. Während die direkte Verwendung oft serverseitige Ressourcen schont, vereinfacht die indirekte Variante die Implementierung.

Die eigentliche Programmlogik oder der Prozessfluss der Anwendung ist auf einem Server hinterlegt. Dies geschieht beispielsweise in Form von EJBs, .NET-Komponenten oder aber in Form von Skript-Komponenten, wie sie beispielsweise von der Skriptsprache Ruby zur Verfügung gestellt werden. Das Ajax-Konzept selbst erfordert keine spezifische Technik, mittels derer die Server-seitige Programmlogik umgesetzt werden muss. Sowohl der Server als auch die Anwendungslogik werden im Ajax-Kontext als Server-Plattform bezeichnet.

Eine wesentliche Aufgabe des Servers bei Ajax Applikationen ist die Bereitstellung der im Browser benötigten Komponenten. Da aufgrund der Sicherheitseinstellungen der Browser ein Cross-Site Scripting nicht erlaubt ist, muss der Web-Server auch Daten von anderen Servern für den Client zur Verfügung stellen und damit die Funktion eines Proxy-Rechners übernehmen.

Der größte Vorteil der Ajax-Technologie ist die Tatsache, dass Daten verändert werden können, ohne dass die komplette Webseite vom Webbrowser neu erzeugt werden muss. Dies erlaubt es Webanwendungen, auf Benutzereingaben schneller zu reagieren. Zudem wird vermieden, dass statische Daten, die sich unter Umständen nicht geändert haben, fortwährend über das Internet übertragen werden müssen. Da die Ajax-Technologien frei zugänglich sind, werden sie unabhängig vom Betriebssystem von den Webbrowsern unterstützt, die auch JavaScript unterstützen. Ein Browser-Plugin wird nicht benötigt. Dies setzt voraus, dass die JavaScript-Unterstützung nicht deaktiviert wurde – genau das stellt den größten Kritikpunkt und die größten Probleme beim Einsatz dar. Vergleichbare Techniken, wie etwa Macromedias Shockwave oder Flash, sind jedoch immer noch mit dem Nachteil behaftet, dass sie ein Browser-Plugin benötigen und nicht immer für alle Plattformen verfügbar sind.

Wie es auch bei DHTML-Anwendungen zur Praxis geworden ist, muss auch eine Ajax-basierte Anwendung rigoros getestet werden, um so die Eigenarten der diversen Webbrowser entsprechend behandeln zu können. Im Laufe der Zeit hat sich die Ajax-Technologie weiter entwickelt, was dazu führte, dass für diese nun diverse Programmbibliotheken zur Verfügung stehen. Diese können zu einer fehlerfreien und einfacheren Anwendungsprogrammierung beitragen.

Es wurden ebenfalls Techniken entwickelt, wie beispielsweise die von Microsoft entwickelte Webforms-Technologie oder die von Sun entwickelte JSF-Technologie, die es ermöglichen, Anwendungen zu entwerfen, die einer Desktop-Anwendung nahe kommen. Zudem bieten diese die Möglichkeit, auch Benutzer, die einen Webbrowser ohne JavaScript-Unterstützung einsetzen, in geeigneter Weise zu bedienen. Der Browser-Typ des jeweiligen Benutzers wird hierbei serverseitig ermittelt, sodass es möglich ist, diesem nur HTML-Seiten zu schicken, die auch von dessen Webbrowser dargestellt werden können.

Einer der häufigsten Vorwürfe gegen die Ajax-Technologie ist die Tatsache, dass es schwer möglich ist, die Funktionalität des Zurück-Knopfs des Browsers zu gewährleisten^[6]. Es besteht die Gefahr, dass das Drücken des Zurück-Knopfs nicht den vorherigen Zustand der Anwendung wiederherstellt, da Browser für gewöhnlich nur statische Seiten in ihrer Historie abspeichern. Das Unterscheiden zwischen einer statischen Seite, die gänzlich in den Cache des Browsers geladen wurde, und einer Seite, die auf dynamische Weise verändert wurde, mag knifflig sein. Grundsätzlich erwartet ein Benutzer, dass ein Drücken des Zurück-Knopfs die zuletzt getätigte Aktion revidiert. Auch wird oftmals durch das Drücken des Zurück-Knopfs versucht, eine Seite im Navigationspfad zurück zu blättern. Ob der Dynamik, mit welcher viele Ajax-Anwendungen behaftet sind, ist dies nicht immer möglich, da die einzelnen Navigationsschritte des Nutzers technisch nur sehr schwer reproduzierbar sind. Software-Entwickler haben verschiedenste Lösungen erfunden, um diesem Problem zu begegnen. Die meisten Lösungen basieren auf so genannten Iframes, weiteren HTML-Elementen. Das Iframe-Element ist so gestaltet, dass dieses für den Nutzer nicht sichtbar ist, und wird benutzt, um die Browser-Historie des Nutzers auf diesem Umweg zu befüllen. (Google Maps führt z. B. eine Suche in einem nicht sichtbaren Iframe-Element durch und befüllt mit den daraus resultierenden Ergebnissen das Ajax-Element der sichtbaren Webseite). Das Dojo-Toolkit erlaubt es, die einzelnen Ajax-Anforderungen mittels einer so genannten Rückruffunktion (engl. callback function) zu verfolgen. Der Rückruf wird immer dann ausgelöst, wenn der Nutzer den Zurück-Knopf des Browsers betätigt. Über diesen Umweg ist es möglich, den vorherigen Zustand der Anwendung wiederherzustellen.

Datei:HTTP-Request-Response-Verhalten.png

Da Webserver nicht in der Lage sind, asynchrone Events an einen Ajax-Client auszuliefern, muss der Ajax-Client seinerseits permanent beim Webserver nachfragen (das eigentliche Polling), ob ein neues Event erzeugt wurde bzw. eine Änderung im Anwendungszustand stattgefunden hat. Dies erzeugt eine völlig andere Auslastung auf einem Webserver, verglichen mit der Last die von herkömmlichen Anwendungen erzeugt wird.

Um ein andauerndes Polling zu vermeiden, wurde die Technik entwickelt, Poll-Anfragen solange zurück zu halten, bis ein tatsächliches Ereignis oder ein Timeout eintritt. Folglich ist mit einer Ajax-Anwendung im Idealfall serverseitig eine Anfrage verknüpft, die letztlich dazu benutzt werden kann, dem Anwendungs-Client beim Eintreten eines entsprechenden Events eine Antwort zu schicken.

Diese Technik wirft allerdings neue Probleme auf. Bisher war es üblich, pro Anfrage an den Server einen Thread zu erzeugen, dessen Ressource sofort nach dem Abarbeiten der Anfrage wieder freigegeben werden konnten. Bei der beschriebenen Polling-Technik kann der Thread nach dem Abarbeiten der Anfrage jedoch nicht de-allokiert werden. Es bleiben also weiterhin Ressourcen, wie beispielsweise Speicher, belegt. Dieses Problem stellt neue Anforderungen an die Skalierbarkeit einer Ajax-Anwendung. Eine mögliche Lösung dieses Problems ist die Verwendung eines Application Servers, der das Prinzip der Fortsetzung (engl. Continuation) unterstützt.

Ein durchaus ähnlich gelagertes Problem ist die Tatsache, dass es bei Webseiten, die dynamisch aktualisiert werden, beinahe unmöglich ist, ein Lesezeichen auf einen ganz bestimmten Zustand einer Webanwendung zu setzen. Auch für dieses Problem wurden zwischenzeitlich Lösungen entwickelt. Meistens wird in diesem Zusammenhang der Anker in der gegenwärtigen URL verwendet, der nach der Raute (#) steht. Auf diese Weise ist es möglich, den Prozessfluss einer Anwendung zu verfolgen. Zudem wird es dem Benutzer so ermöglicht, über den genannten URL-Teil einen bestimmten Anwendungszustand wiederherzustellen. Viele Webbrowser ermöglichen es, den Anker durch JavaScript dynamisch zu aktualisieren. Dies ermöglicht es einer Ajax-Anwendung, den Inhalt der dargestellten Webseite parallel zur Verarbeitung zu aktualisieren. Diese Lösungsansätze beheben auch einige der Probleme, die durch den nicht funktionierenden Zurück-Knopf entstehen.

Datei:Ajax-MVC-Modell (Variante I).png

Die Latenzzeit, also das zeitliche Intervall zwischen einer HTTP-Anfrage des Browsers und der zugehörigen Server-Antwort, muss bei der Entwicklung einer Ajax-Anwendung berücksichtigt werden. Ohne eine klar ersichtliche Rückmeldung für den Benutzer ^[7], vorausschauendes Laden einzelner Anwendungsdaten ^[8] und einem korrekten Umgang mit dem XMLHttpRequest-Objekt ^[9] kann sich einem Benutzer der Eindruck aufdrängen, dass die gesamte Anwendung nur zähflüssig auf dessen Aktionen reagiert. Für gewöhnlich ist dies ein Umstand, der sich dem Benutzer nur schwer erschließt ^[10]. Aus diesem Grund ist es wichtig, so genannte visuelle Feedbacks wie beispielsweise das Symbol einer Sanduhr zu verwenden, um den Benutzer darauf aufmerksam zu machen, dass momentan gewisse Hintergrundaktivitäten stattfinden oder Daten bzw. Inhalte geladen werden.

Unabhängig von den technischen Schwierigkeiten von Ajax gab es in der Vergangenheit immer wieder Kritik daran, dass das Unternehmen Adaptive Path, welches den Begriff Ajax ursprünglich geprägt hat, oder andere Unternehmen den Begriff als Marketing-Vehikel benutzen. In diesem Zusammenhang wird vor allem deshalb Kritik geübt, da die Grundlagen von Ajax vor der Prägung des Begriffs entwickelt wurden. Allerdings hat die Prägung des Begriffs auch dazu beigetragen, die Diskussion rund um den Browser als Fat Client neu zu beleben.

Datei:Ajax-MVC-Modell (Variante II).png

Zwar unterstützt eine Ajax-basierte Umgebung nicht per se das MVC-Architekturmuster, jedoch kann dieses sehr einfach umgesetzt werden. Eine Umsetzung kann das gesamte Browser-Fenster als Grundlage für die Präsentationsschicht haben. Auch ermöglicht es Ajax, ein zyklisches bzw. geschachteltes MVC-Modell umzusetzen. In diesem Fall besitzen einzelne Präsentationsschicht-Elemente einer Webseite sowohl einen separaten Controller als auch ein separates Modell. Beide Zusammenhänge sind in den Abbildungen dieses Artikels dargestellt.

Soll die Ajax-Technologie eingesetzt werden, so stellt dies eine Herausforderung dar, wenn die Webanwendung den WAI-Regeln folgen soll. Software-Entwickler müssen aus diesem Grund Alternativen anbieten, wenn eine Webseite beispielsweise auch für sehbehinderten Nutzer mit einem Screenreader zugänglich sein soll. Dies ist notwendig, da die Mehrzahl aller Ajax-Anwendungen für herkömmliche grafische Webbrowser entworfen wurden.

Es gibt verschiedene Möglichkeiten, eine Ajax-Anwendung einer Suchmaschine zugänglich zu machen. Die einzelnen Ansätze variieren im Grad der Indizierung, der erreicht werden kann, und der Art, wie dies erreicht wird. Für einige Webseiten, wie beispielsweise die eines Studiengangs einer Universität, ist es notwendig, dass jeder einzelne Bereich durch eine Suchmaschine erfasst werden kann. Eine Seite jedoch, die einen Webmail-Service zur Verfügung stellt, wird dies nicht erforderlich machen. Nachfolgend sind einige Strategien genannt, die es ermöglichen, einen Webauftritt durch eine Suchmaschine indizieren zu lassen:

• Lightweight Indexing: An der eigentlichen Webseite werden keine strukturellen Änderungen vorgenommen. Es werden jedoch bereits existierende Elemente, wie beispielsweise Meta-Tags oder Überschriften-Elemente für die Indizierung verwendet.
• Extra Link Strategy: Zusätzliche Links werden auf der Webseite platziert, denen Suchroboter folgen können, um so den gesamten Webauftritt indizieren zu können. Die zusätzlichen Links müssen nicht sichtbar sein, da sie nur für den Suchroboter einer Suchmaschine gedacht sind.
• Secondary Site Strategy: Eine zweite Webseite wird entworfen. Diese ist für eine Suchmaschine voll zugänglich.

Viele Ajax-Toolkits versenden XML-Daten, indem sie die in diesem Bereich gängige UTF-8-Zeichenkodierung ^[11] benutzen. Manche Toolkits erfordern es auch, dass XML-Daten, die vom Webserver zum Webbrowser des Nutzers geschickt werden, in UTF-8 kodiert sein müssen. Wenn die Webseite selbst aber eine andere Zeichenkodierung benutzt, kann dies zu Konflikten mit den UTF-8-basierten XML-Daten führen. Eine mögliche Ursache ist, dass in einem XML-Dokument keine Entity-Referenzen (character entity reference) wie z.B. ö für das Zeichen „ö“ verwendet werden können – es sei denn, sie sind in einer eingebetteten Dokumenttypdefinition definiert oder das XML-Dokument ist nach ISO-8859-1 Zeichenkodierung erstellt worden. HTML hingegen gibt zahlreiche solcher Entities vor. In XML-Dokumenten ohne Dokumenttypdefinition können hingegen nur numerische Zeichenreferenzen (numeric character reference) verwendet werden.

<?xml version="1.0" encoding="utf-8" ?>
<anfang>
  <copyright>&#169; 2006 Hans Wurst</copyright>
</anfang>

Unicode-basierte XML-Dokumente verwenden numerische Zeichenreferenzen, HTML-Dokumente jedoch nicht zwangsweise.

<html>
  <head>
    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body>
    <p>&copy; 2006 Hans Wurst</p>
  </body>
</html>

Folgende Webbrowser sind derzeit in der Lage, Ajax-Anwendungen auszuführen. Genannt wird immer nur die erste Software-Version, die es ermöglichte, Ajax-Anwendungen auszuführen. Alle Folgeversionen implizieren dieselbe Unterstützung.

Name	Erste Version mit Ajax-Unterstützung	Native Unterstützung	Unterstützung durch ein AddOn	Kommentar
Microsoft Internet Explorer	5.0	- (ab 7.0)	ja (ActiveX-Komponente)	Die Version 4.0 unterstützte erstmals XML, jedoch nicht die für Ajax notwendige XMLHttpRequest-API. Diese API wurde später als ActiveX-Komponente realisiert und ist seit Version 7.0 nativer Bestandteil des IE. Browser, die auf der IE-Technologie aufbauen, sind ebenfalls Ajax-kompatibel.
Mozilla Firefox	1.0	ja	-	d. h. die Gecko-basierte Familie der Mozilla-Browser
Opera	8.0	ja	-	-
Apple Safari	1.2	ja	-	-
Netscape	7.1	ja	-	-
Konqueror	?	ja	-	Das HTML-Rendering etc. wird durch die KHTML realisiert. Diese ist auch Bestandteil des Safari Browsers.
iCab	3.0 Beta	ja	-	Ältere Version wie beispielsweise die Version für m68k-basierte Computer unterstützen kein Ajax.

Die nachfolgenden Weblinks referenzieren typische Vertreter einer Anwendung auf Ajax-Basis. Einige haben durch ihre neuartige, intuitiv zu bedienende Benutzeroberfläche einen gewissen Bekanntheitsgrad erlangt. Die Linkliste selbst kann in diesem Zusammenhang ob der aktuellen Vielfalt an Ajax-Anwendungen nur eine beispielhafte Auswahl darstellen und ist bewusst sehr kurz gehalten.

• Virtuelle Globen / Virtuelle Landkarten
  • Google Maps – interaktive Weltkarte
• Webbasierte Büroanwendungen
  • AjaxWrite – Textverarbeitung
  • iRows – Tabellenkalkulation
  • nexImage – Web-basiertes Bildbearbeitungswerkzeug
• Anwendungen, welche die Wikipedia nutzen
  • LuMriX Wikipedia Suche
  • Gollum Wikipedia-Browser
• Soziale Software
  • Flickr – Webanwendung zur Verwaltung von Fotos
  • Del.icio.us – Web-basiertes, kommunales Bookmark-System, schlägt "Tags" und Begriffe vor
• Vermischtes
  • Google Mail – ist ein Webmail-Anbieter. Dieser bietet eine Art E-Mail-Programm für den Webbrowser an.
  • Google Suggest – zeigt Vorschläge an, die der Benutzer suchen könnte
  • Periodensystem der Elemente mit Online-Datenabfrage realisiert als SVG-Anwendung (lauffähig mit Plug-in von Adobe oder nativ ab Firefox 1.5)

• DHTML
• JSON
• Web 2.0
• Web Service
• WinLIKE
• AFLAX (englisch)
• SPA (englisch)

1. ↑ Ajax Patterns - On-Demand Javascript
2. ↑ Microsoft Remote-Scripting Anfänglich als Java-Applet umgesetzt, wurde später durch ein IFrame-Element ersetzt.
3. ↑ Microsoft: XML versions that are included with Microsoft Internet Explorer Knowledge Base Q269238 - Version list for the Microsoft XML parser
4. ↑ Stellungname des Unternehmens Zimbra, Inc. bezüglich der Open Ajax Initiative
5. ↑ Browserunabhängie Ajax-Engine auf der Basis der Web Services Technologie
6. ↑ Jakob Nielsen: Top-10 New Mistakes of Web Design, 1999
7. ↑ Remote Scripting with AJAX, Part 2
8. ↑ Jonathan Boutelle: Latency Must Die: Reducing Latency by Preloading Data, 2004-08-26
9. ↑ Ajax Blog - HTML, Javascript and XML coding techniques for Web 2.0 Async Requests over an Unreliable Network
10. ↑ Marcus Baker: Listen kids, AJAX is not cool, 2005-06-03
11. ↑ SELFHTML-Zeichenreferenz: UTF-8 und ISO 8859-1 Zeichenkodierung

• Ajax
  • Jesse James Garrett: Ajax: A New Approach to Web Applications. Adaptive Path LLC, 18. Februar 2005, [1] (Der Aufsatz, der den Namen geprägt hat. In englischer Sprache)
  • Olaf Bergmann, Carsten Bormann: AJAX - Frische Ansätze für das Web-Design. 1. Auflage. SPC TEIA Lehrbuch Verlag, Oktober 2005, ISBN 3935539266 (HTML-Variante des Buchs)
  • Johannes Gamperl: Ajax. Galileo Computing, März 2006, ISBN 3-89842-764-1
  • Ralph Steyer: Ajax mit PHP. Addison-Wesley, März 2006, ISBN 3-8273-2358-4
  • Stuart Langridge: DHTML Utopia. SitePoint, 30. Juni 2005, ISBN 0957921896 (englisch)
  • Ryan Asleson, Nathaniel T. Schutta, Nate T. Schutta: Foundations of Ajax. Apress, 17. Oktober 2005 ISBN 1590595823
  • Dave Crane, Eric Pascarello: Ajax in Action. Manning Publications, November 2005, ISBN 1932394613 (einzelne Kapitel als Online-Version, in englischer Sprache)
  • Cameron Adams, James Edwards: JavaScript Anthology. SitePoint, Dezember 2005, ISBN 0-9752402-6-9
• Web-Programmierung
  • Louis Rosenfeld, Peter Morville: Information Architecture for the World Wide Web. 2. Auflage. O'REILLY, August 2002, ISBN 0596000359 (sehr gute Lektüre, die auch die Probleme behandelt, die beim Einsatz der Ajax-Technologie auftreten können)
  • Jennifer Fleming: Web Navigation. O'REILLY, Mai 1999, ISBN 1565923510

• Artikel im Mozilla developer Center zu Ajax. Mit einer Grundlage auf deutsch
• Wiki mit Beispielen zu Ajax (englisch)

Vorlage:Lesenswert Kandidat