Hallo,

Im Artikel Ajax: A New Approach to Web Applications wurde ursprünglich der Begriff »Ajax« erfunden und als Abkürzung für »Asynchronous JavaScript and XML« eingeführt.

Nach mehrmaligem Lesen ist mir zwar klar, was Garrett mit der Asynchronität meint, aber mir fällt keine Ajax-Anwendung ein, die in diesem Sinne asynchron arbeitet.

Vor allem bezweifle ich eine seiner Kernthesen:

»An Ajax application eliminates the start-stop-start-stop nature of interaction«

Ich denke nicht, dass das zutrifft, aber sehen wir erst einmal weiter.

»The Ajax engine allows the user’s interaction with the application to happen asynchronously — independent of communication with the server. So the user is never staring at a blank browser window and an hourglass icon, waiting around for the server to do something.«

Dazu habe ich einzuwenden:

1. Die Ajax-Anwendung hat zu einem bestimmten Zeitpunkt gewisse Daten vorgehalten. Klickt der Benutzer irgendwelche Schaltflächen und führt gewisse Aktionen aus, so können diese Daten präsentiert werden. Auf unterschiedliche Weise. Bestimmte Daten werden gezeigt, andere versteckt. Sie können auch manipuliert werden. Soweit klar.

2. Natürlich kann man durch Event-Steuerung verschiedene Funktionen gleichzeitig parallel laufen lassen. Zwei Klicks an unterschiedlicher Stelle und es können gleichzeitig zwei Operationen durchgeführt werden, die dann irgendwann unabhängig voneinander enden.

3. Wenn ich jetzt irgendwelche Funktionen ausführe, die Kommunikation mit dem Server erfordern, so wird hängt das Weiterarbeiten zumindest teilweise von der Serverantwort ab. Der Benutzer klickt also und sofort wird ein Request gestartet. Fast alle Ajax-Anwendungen zwingen den Benutzer nun, auf die Beantwortung dieses Requests zu warten. Sie blockieren in diesem Moment und sind nicht bzw. nur teilweise weiter bedienbar. Klicke ich z.B. auf »Zeige die nächsten Einträge«, so wird ein Request abgesetzt und ich muss WARTEN, bis die Antwort eintrudelt und dargestellt wird. Das ist doch Start-Stop-Start par excellence?!

Meiner Wahrnehmung nach ist Ajax faktisch eine Renaissance der Bitte-Warten-Icons 1 2. Ich habe noch nie soviele »Loading«-Animationen gesehen wie seit dem Ajax-Umsturz. Wo bleibt da die Asynchronität?

Natürlich, es gibt einige Requests, die man absendet und nicht auf die Antwort wartet. Die Oberfläche ändert sich sofort, als wäre der Request schon serverseitig erfolgreich abgearbeitet. In REST-Kategorien sind das POST-, PUT- oder DELETE-Request (letztlich löst die niemand über diese HTTP-Anfragen, statt PUT und DELETE muss meist POST hinhalten, REST nenne ich als praktisches Modell, dass diese Anfragetypen unterscheidet).

Gut, aber viel üblicher sind doch die GET-Requests, die Daten vom Server beziehen, anstatt nur auf das OK zu warten, dass die letzte Aktion fehlerfrei durchgeführt wurde.  Und genauso ist es üblich, auch bei POST, PUT und DELETE auf die positive (oder negative) Serverantwort zu warten und erst dann das visuelle Feedback für »Erfolg!« zu geben. Das hat auch einige Vorteile. Wenn ich z.B. eine Verwaltung von Texten habe habe und einen Löschen-Button drücken, interessiert es mich, ob der Server die Anfrage korrekt abgearbeitet hat. Wenn man den Text im Moment des Buttondrucks vom Bildschirm löscht, so besteht das Problem, dass er bei einem Serverfehler o.ä. z.B. wieder eingeblendet werden müsste.

JSONP ist wohl ein gutes Beispiel. Natürlich kann man auch POST-, PUT- und DELETE-Operationen in JSONP lösen, der Server würde dann wohl nur callback({status : 200}) zurückgeben. Aber JSONP ist speziell für GET gedacht, und zwar *synchrones*. Wenn ich ein script-Element einbinde mit einer JSONP-Adresse, so kann ich erst wissen, ob der Request überhaupt abgesendet wurde, wenn der Callback-Handler abgerufen wird. Sprich, es ist unmöglich, asynchron zu arbeiten.

Weiter zu den mehr oder weniger anschaulichen Diagrammen:

http://adaptivepath.com/images/publications/essays/ajax-fig2.png

Was er dort als asynchron darstellt, kann ich mir nicht konkret vorstellen.

Im zweiten Diagramm fängt es an mit: Der Input löst direkt einen Request aus und der Server wird sofort kontaktiert. Auf Serverantwort wird nicht gewartet, sondern Display ändert sich vorher. Die Antwort trifft ein und es findet in dem Moment *keine* Display-Änderung statt. Okay, das kann etwa ein DELETE-Request sein. Das Item wird auf dem Bildschirm sofort gelöscht, auch wenn der Server noch nicht zurückgemeldet hat, dass es dort korrekt gelöscht wurde.

Jetzt kommt ein Punkt, den ich nicht verstehe:

Es gibt einen weiteren Input (zweiter Input-Pfeil), soweit klar. Aber dann vergeht Zeit, in der nichts geschieht. Dann plötzlich, einige unbestimmte Zeit nach dem Input, sendet die Ajax-Engine einen Request zum Server. Wieso das? Ist dieser Request denn keine Reaktion auf den zweiten Input? Ich kenne keine Ajax-Engine, die ohne direkte oder indirekte Benutzereingabe präemptiv bzw. mit Verzögerung zu einer Benutzereingabe mit dem Server kommuniziert. Welchen Zweck sollte das haben.

Ok, mit viel Phantasie könnte ich mir das erklären. Aber: Nachdem dieser (zweite) Request bearbeitet und beantwortet wurde, kommt kein direktes visuelles Feedback. Was mag das für ein Request sein? Irgendwas wird im Hintergrund abgefragt, ohne dass das Ergebnis direkt verwendet wird? Wird vielleicht nur abgefragt, ob die vorgehalteten Daten noch aktuell sind? So könnte ich mir das erklären. Mit viel Spekulation.

Der dritte Input-Pfeil und der unbestimmte Zeit darauf folgende dritte Request sind auch so ein Fall. Wieso vergeht zwischen Input und Request Zeit? Ok, auch das könnte man sich erklären. Ich frage mich nur, warum so eine Zeit zwischen Input und Request nicht beim ersten Input bzw. Request berücksichtigt wurde. Denn dort gibt es ein Punkt auf der Zeitleiste, an dem der Input *sofort* den Request auslöst. Warum der zweite und dritte Request im Vergleich dazu scheinbar ohne Zusammenhang zum Input dargestellt werden, verstehe ich nicht.

Der vierte Request letztlich ist auch dubios: Er wird durch keinen Input ausgelöst. Wohl auch eine Abfrage im Hintergrund, die durch irgendeinen Timer angestoßen wurde. Interessanterwese findet das Eintreffen der Antwort gleichzeitig mit deem letzten Display statt. Ok, das erkläre ich mir so, dass dieser Request ohne konkreten Auslöser durch einen Input abgefragt, ob es serverseitig etwas Neues gibt, und das ist der Fall (z.B. »Sie haben Post!«). Dann frage ich mich nur, ob dem vierten und letzten Input nicht direkt eine Display-Änderung entspricht.

Chaos hoch drei also. Ich kann viel herumrätseln und mir den Kopf über diesem Diagramm zerbrechen. Letztlich denke ich, dass ich viel zu viel in das Diagramm hineinlese und Garrett die Pfeile einfach willkürlich verteilt hat - um eben den diffusen Eindruck der Asynchronität von Input, Display und Request/Response zu erwecken.

Meine These ist: Faktisch gibt es keine solche Asynchronität bei den meisten Operationen der verbreiteten Ajax-Anwendungen. Der zeitlichen Abfolge und vor allem der Kausalität von Eingabe, Serveranfragen und visuelles Feedback einer realen Ajax-Anwendung entspricht dieses Diagramm auf keinen Fall - beziehungsweise, man zeige mir, welche Ajax-Anwendung tatsächlich in dieser Weise »asynchron« arbeitet.

Was ist nun das Asynchrone an Ajax?

Ohne »A« in Ajax wird es ein ziemliches Nullwort. Zumeist kommen weder »asynchronous« noch »XML« vor. Übrigens bleibt das »J« für JavaScript. Sagt der Begriff überhaupt noch etwas?

Mathias