Nachtrag: Ajax und Asynchronität

[molily]

Hallo,

Vor einiger Zeit fragte ich mich: Was ist das Asynchrone an Ajax?

ppk stellt sich in seinem Blog eine ähnliche Frage:
Is asynchronous communication really being used?

Es geht darum, ob Ajax-Anwendungen wirklich das übliche Schema durchbrechen: Benutzeraktion → Server-Anfrage wird gestartet, derweil »friert« die Anwendung quasi ein und der Anwender wartet → Anfrage wird auf dem Server bearbeitet und zurückgesendet → Antwort kommt beim Browser an, das Interface wechselt bzw. es gibt eine entsprechende Rückmeldung. Die Anwendung wird »freigegeben«, der Benutzer kann andere Operationen vornehmen.

Auch ppk kommt zu dem Schluss, dass die namensgebende Eigenheit von Ajax gemäß dem Erfinder des Claims – das Klicken-Warten-Antwort-Schema wird durchbrochen - bei den üblichen Ajax-Anwendungen gar nicht bestimmtend ist.

Das bestärkt mich in der Ansicht, dass Garrett einfach Unrecht hatte. Was heute unter dem Label Ajax läuft, hat wenig mit seinem »Ajax web application model (asynchronous)« zu tun. Ajax-Anwendungen arbeiten zum großen Teil synchron, was das Warten auf die Server-Rückmeldung angeht. Nur in wenigen Fällen ist die Rückmeldung unwichtig, sodass man die Anfrage absenden kann und nicht auf die Rückmeldung warten braucht.

Mathias

[Cheatah]

Hi,

Das bestärkt mich in der Ansicht, dass Garrett einfach Unrecht hatte. Was heute unter dem Label Ajax läuft, hat wenig mit seinem »Ajax web application model (asynchronous)« zu tun. Ajax-Anwendungen arbeiten zum großen Teil synchron, was das Warten auf die Server-Rückmeldung angeht.

nicht wirklich. Wäre es synchron, könnte der Browser (bzw. zumindest diese Instanz) während dessen nicht verwendet werden. Es mag zwar stimmen, dass der Aspekt der Asynchronizität aus Sicht von JavaScript nicht wichtig ist - aus Sicht der Anwendung ist er aber der _entscheidende_ Vorteil praktisch jeder AJAX-Nutzung, die ich je gesehen habe.

Cheatah

[molily]

Hallo,

Wäre es synchron, könnte der Browser (bzw. zumindest diese Instanz) während dessen nicht verwendet werden.

Natürlich, das hat auch niemand bezweifelt.

Um diese Asynchronität geht es hier nicht, wie die Links auch deutlich machen. Es geht um das »synchronous interaction pattern of a traditional web application«. Tatsächlich folgen auch Ajax-Anwendungen diesem Modell.

Mathias

[Harlequin]

Hi,

Um diese Asynchronität geht es hier nicht, wie die Links auch deutlich machen. Es geht um das »synchronous interaction pattern of a traditional web application«. Tatsächlich folgen auch Ajax-Anwendungen diesem Modell.

Das dürfte vor allem daran liegen, dass der User selbst nicht in der Lage ist asynchron zu arbeiten. Meistens will man genau ein Ziel erreichen und dazu wird eine bestimmte abfolge von Schritten benötigt. Da die Schritte aber normalerweise voneinander abhängen muss zwangsläufig immer auf das Ende des vorherigen Schrittes gewartet werden.

Gruß,

Harlqeuin

[wahsaga]

hi,

Das dürfte vor allem daran liegen, dass der User selbst nicht in der Lage ist asynchron zu arbeiten. Meistens will man genau ein Ziel erreichen und dazu wird eine bestimmte abfolge von Schritten benötigt. Da die Schritte aber normalerweise voneinander abhängen muss zwangsläufig immer auf das Ende des vorherigen Schrittes gewartet werden.

Eben.
Mir fallen gar nicht so viele Beispiele ein, wo man AJAX wirklich asynchron und gleichzeitig sinnvoll nutzen könnte - in "typischen" Webapplikationen.

Sowas wie die Bewertungsfunktion hier im Forum vielleicht, oder ähnliches, wo der Benutzer etwas zur Verarbeitung an den Server übergibt, wo ihn das Ergebnis aber (sofern kein Fehler auftritt) für die weitere Nutzung der Webseite gar nicht interessiert.

Aber wo hat man sowas schon mal?

Wirklich langdauernde Operationen - eine komplizierte serverseitig durchgeführte Suche/Sortierung/Objekterstellung kommt im Web-Bereich nicht so häufig vor.
Und selbst wenn - damit ich die Web-Applikation inzwischen nach belieben weiternutzen könnte, müsste sie komplett AJAX-basiert sein. So dass ich bspw. inzwischen andere Inhalte nachladen und anschauen kann, für die ich "normalerweise" auf eine weitere Unterseite wechseln würde - damit wäre aber das AJAX-Script gekillt, und es bräuchte jetzt einen PUSH vom Server, um mich darüber zu informieren, wenn die vorher angetstartete langwierige Aktion endlich mal fertig geworden ist.
Eine solche komplett AJAX-basierte Applikation, bei der Bookmarken von Einzelinhalten so gut wie unmöglich ist, hätte dann aber nichts mehr mit der "klassischen" Website zu tun, auf der Struktur vor allem durch unterschiedliche URLs hergestellt wird.

gruß,
wahsaga

[Rouven]

Hi,

stimmt schon. Das einzige wo es mir bisher mal als annähernd sinnvoll erscheint ist eine "Anwendung" bei uns am System: Verschiedene Datenquellen sind über ein großes Netz und einen Such-Prozess verbunden, d.h. irgendwer stellt irgendwo eine Anfrage, die wird durch das System durchgejagt und entsprechend der Prozessvorgabe werden die Quellen abgearbeitet. Eine dieser Quellen können menschliche Mitarbeiter sein, die ein Webfrontend haben. Da ist es nun so, dass sowohl die Liste der derzeit offenen Fragen als auch Antwortbereich gleichzeitig auf dem Bildschirm angezeigt werden. Die Liste der offenen Fragen refresht sich alle paar Sekunden, eine Aufgabe die man natürlich auch mit einem echten reload machen könnte, die bei uns aber über AJAX läuft, so dass die Oberfläche die ganze Zeit unangetastet offen und benutzbar bleibt.

MfG
Rouven

[wahsaga]

hi,

Die Liste der offenen Fragen refresht sich alle paar Sekunden, eine Aufgabe die man natürlich auch mit einem echten reload machen könnte, die bei uns aber über AJAX läuft, so dass die Oberfläche die ganze Zeit unangetastet offen und benutzbar bleibt.

Wobei ich auch in so einem Fall AJAX nur als "Krücke" sehe, die ein im HTTP-Umfeld nicht verfügbares PUSH etwas angenehmer für den Nutzer simuliert.

Allzu asynchron ist diese Methodik m.E. aber auch nicht - es wird ja trotzdem so lange regelmässig beim Server nachgefragt, bis das Ergebnis bereitsteht.

Ich habe bei der Benutzung des Names AJAX immer leichte Bedenken - nur von XMLHTTPRequest zu sprechen, gefällt mir sehr viel besser.
Das ist ein Objekt, welches mir ich endlich die Möglichkeit gibt, mit Javascript Daten "nachzuladen", ohne das über versteckte Iframes o.ä. machen zu müssen.
Ob ich die dabei empfangenen Daten synchron oder asynchron weiterverarbeite, impliziert die Verwendung des Objektes XMLHTTPRequest noch überhaupt nicht.

Wie schon gesagt, geben m.E. die im www "typischen" Arbeitsschritte und Aktionen meistens gar keine dankbaren Anwendungsfelder für eine wirkliche Asynchronität her.

AJAX wird nicht automatisch dadurch asynchron, dass ich beim XMLHTTPRequest das Flag dafür entsprechend setze.
Ich würde vermuten, dass in einem großen Teil der aktuellen "AJAX"-Applikationen die Asynchronität der Behandlung des abgesetzten Requests ohne weiteres durch eine synchrone ersetzt werden könnte, ohne dass der Benutzer dies überhaupt bemerken würde.

gruß,
wahsaga

[molily]

Hallo,

Ich habe bei der Benutzung des Names AJAX immer leichte Bedenken - nur von XMLHTTPRequest zu sprechen, gefällt mir sehr viel besser.
Das ist ein Objekt, welches mir ich endlich die Möglichkeit gibt, mit Javascript Daten "nachzuladen", ohne das über versteckte Iframes o.ä. machen zu müssen. (...)

Die Erkenntnis erscheint mir auch sehr wichtig - andererseits ist XMLHttpRequest auch nur ein mögliches Mittel, um Daten zu übertragen bzw. nachzuladen. Es bedarf also schon eines übergeordneten Begriffes für dieses Konzept. Der Begriff »Ajax« scheidet aus naheliegenden Gründen aus. Das Garrett-Programm halte ich für wenig erkenntnisfördernd, einem Neuling hilft es wenig, weil es nicht auf die typischen Ajax-Anwendungen passt. Und der Name »Asynchronous JavaScript and XML« ist am unpassendsten. Asynchronous: In einem gewissen Sinne, aber selten in dem Sinne, den Garrett als essentiell hochhält. JavaScript: Ja, gut, meistens bzw. momentan ist es JavaScript im WWW, das Konzept aber ist erst einmal neutral gegenüber möglichen Scriptsprachen. XML: Keinesfalls zwangsläufig, in der Praxis sogar recht selten (siehe AJAH, AHAH, JAHAH usw. usf.).

Gut, ich habe nichts dagegen, das Konzept ganz beliebig ohne tiefere Bedeutung Ajax zu nennen, so wie Spunk. Aber man sollte die Utopien von Garrett außen vor lassen und bloß nicht mit »Asynchronous JavaScript and XML« anfangen. Wenn es einfach um das Konzept geht, nicht immer komplette neue HTML-Dokumente vom Server zu laden, sondern im Hintergrund gezielt strukturierte Daten mit dem Server auszutauschen, so würde ich überhaupt nicht die bedeutungsreiche Vokabel »asynchron« in den Mund nehmen.

Mathias

[Axel Richter]

Hallo,

Ich habe bei der Benutzung des Names AJAX immer leichte Bedenken - nur von XMLHTTPRequest zu sprechen, gefällt mir sehr viel besser.
Das ist ein Objekt, welches mir ich endlich die Möglichkeit gibt, mit Javascript Daten "nachzuladen", ohne das über versteckte Iframes o.ä. machen zu müssen. (...)

Die Erkenntnis erscheint mir auch sehr wichtig - andererseits ist XMLHttpRequest auch nur ein mögliches Mittel, um Daten zu übertragen bzw. nachzuladen. Es bedarf also schon eines übergeordneten Begriffes für dieses Konzept. Der Begriff »Ajax« scheidet aus naheliegenden Gründen aus. Das Garrett-Programm halte ich für wenig erkenntnisfördernd, einem Neuling hilft es wenig, weil es nicht auf die typischen Ajax-Anwendungen passt. Und der Name »Asynchronous JavaScript and XML« ist am unpassendsten. Asynchronous: In einem gewissen Sinne, aber selten in dem Sinne, den Garrett als essentiell hochhält. JavaScript: Ja, gut, meistens bzw. momentan ist es JavaScript im WWW, das Konzept aber ist erst einmal neutral gegenüber möglichen Scriptsprachen. XML: Keinesfalls zwangsläufig, in der Praxis sogar recht selten (siehe AJAH, AHAH, JAHAH usw. usf.).

*g*

Asynchronous or Synchronous, but often Synchronous, HTTP-Requests from a Script Inside a Document displayed in a Web Browser Window = ASSHRSIDWBW

bischen sperrig ;-)

andere Vorschläge?

viele Grüße

Axel

[MudGuard]

Hi,

Asynchronous or Synchronous, but often Synchronous, HTTP-Requests

... Originating from Local Elements called Script.

oder kurz:

ASSHOLES

cu,
Andreas

[Cybaer]

Hi,

... Originating from Local Elements called Script.

Überlegt hatte ich auch - aber mir ist nichts gutes eingefallen! :-))

Gruß, Cybaer

[Axel Richter]

Hallo,

Asynchronous or Synchronous, but often Synchronous, HTTP-Requests
... Originating from Local Elements called Script.
oder kurz:
ASSHOLES

*räusper* Nu werd ma nich komisch, ne? Außerdem hast Du den Request unterschlagen.

Scripts Inside Documents Enabled to Wide Area Request Documents on its Server

SIDEWARDS

... hat irgendwie was ;-).

viele Grüße

Axel

[MudGuard]

Hi,

Hallo,

Asynchronous or Synchronous, but often Synchronous, HTTP-Requests
... Originating from Local Elements called Script.
oder kurz:
ASSHOLES
*räusper* Nu werd ma nich komisch, ne? Außerdem hast Du den Request unterschlagen.

Nö, ich hab nur HTTP-Requests als ein (zusammengesetztes) Wort betrachtet.

SIDEWARDS
... hat irgendwie was ;-).

Ich find ASSHOLES besser ;-P

cu,
Andreas

[at]

Hallo.

oder kurz:

ASSHOLES

Tiefgründig, aber kaum eingängig. Und die Ergebnisse dieser Technik könnten doch auch nur Scheiße sein.
MfG, at

[Cybaer]

Hi,

ASSHOLES
Tiefgründig, aber kaum eingängig.

Das sagst vielleicht *Du*! ;->

Und die Ergebnisse dieser Technik könnten doch auch nur Scheiße sein.

Oder gar komprimierte Scheiße (ref. "eingängig") ... O;->

Gruß, Cybaer

[Der Martin]

Hallo,

Das dürfte vor allem daran liegen, dass der User selbst nicht in der Lage ist asynchron zu arbeiten.

Ist er das wirklich nicht? Das kommt drauf an, wie du "asynchron" verstehen willst.

Meistens will man genau ein Ziel erreichen und dazu wird eine bestimmte abfolge von Schritten benötigt. Da die Schritte aber normalerweise voneinander abhängen muss zwangsläufig immer auf das Ende des vorherigen Schrittes gewartet werden.

Das ist richtig - aber ich kann als User sehr wohl mehrere solcher Schritt-Abfolgen unabhängig voneinander asynchron anstoßen. Um ein Beispiel zu nennen: Ich lass eine Suchanfrage bei ebay los. Da ich weiß, dass das eine Weile dauert (mehrere Sekunden), stelle ich das Browserfenster in den Hintergrund und rufe in der Zwischenzeit einen Beitrag aus dem SELFForum ab. Schon beim ersten Satz merke ich, dass mich das Thema doch nicht so interessiert, wie ich erst dachte. Aber bevor ich weiterlese, stelle ich fest, dass meine ebay-Suchliste inzwischen da ist, also schau ich da mal schnell rein. Ich hätte kein Problem, noch eine dritte, von den ersten beiden wiederum unabhängige Browser-Session aufzumachen, um beispielsweise ein Stichwort in der Wikipedia nachzuschlagen.
Diese voneinander unabhängigen Aktionen laufen dann tatsächlich asynchron, d.h. mit ohne festen zeitlichen Bezug zueinander.

So long,
 Martin

[molily]

Hallo,

ich kann als User sehr wohl mehrere solcher Schritt-Abfolgen unabhängig voneinander asynchron anstoßen.

Okay, man kann also mehrere voneinander unabhängige Anwendungen in mehreren Browser-Sessions gleichzeitig bedienen, indem man während den »Wartezeiten« umschaltet. Auch das hat niemand bezweifelt - das ist eher Multitasking anstatt Asynchronität.

Denn *in sich* sind die Anwendungen, die du beschreibst, gänzlich synchron in dem Sinne, dass du eine Anfrage initiierst, wartest (bzw. in der Zeit mit einer anderen Anwendung interagierst, aber nicht mit derselben) und dann irgendwann das Ergebnis zu sehen bekommst und weiter mit einen Anwendung arbeitest. Nun sind die von dir genannten Beispiele keine Ajax-Anwendungen, aber selbst wenn sie es wären, würden sie sich wahrscheinlich nicht viel anders verhalten. Und der Punkt steht eben zur Debatte: Ajax wirklich asynchron und wenn ja, wann und wie?

Mathias

[Axel Richter]

Hallo,

Wäre es synchron, könnte der Browser (bzw. zumindest diese Instanz) während dessen nicht verwendet werden.

Natürlich, das hat auch niemand bezweifelt.

Um diese Asynchronität geht es hier nicht, wie die Links auch deutlich machen. Es geht um das »synchronous interaction pattern of a traditional web application«. Tatsächlich folgen auch Ajax-Anwendungen diesem Modell.

Ja. Es kommt aber darauf an, wie man die Synchronität definiert.

Bei normalen Web-Anwendungen, bei denen man davon ausgehen muss, dass der Client nur ein simpler HTML-Browser, ohne clientseitige Programmiersprache ist, erfordert jede Nutzeraktion einen HTTP-Request zum Server. Die serverseitige Programmlogik wird aktiv, generiert ein HTML-Ergebnis und sendet dieses als Response zum Client. Während dieses Vorgangs (HTTP-Request - HTTP-Response) ist die Browserinstanz, die den Request abgesetzt hat, nicht anderweitig benutzbar. Diese Einschränkung resultiert hauptsächlich daraus, dass ein simpler HTML-Browser keine clientseitige Programmiermöglichkeit bietet. Die serverseitige Programmlogik präsentiert dem Nutzer die Daten direkt (synchron) auf dessen Anfrage über den HTML-Browser.

Schon normales clientseitiges JavaScript durchbricht dieses Schema. Nicht mehr jede Nutzeraktion erfordert die Anfrage beim Server. Ein Beispiel wären voneinander abhängige SELECT/OPTION-Elemente. Ohne JavaScript müsste der Server die OPTIONs im abhängigen SELECT-Element generieren. Man müsste also im ersten SELECT-Element auswählen, dann einen HTTP-Request ausführen, welcher die Ressource mit dem abhängigen SELECT-Element zurückliefert. Mit JavaScript ist es denkbar, dass die Daten für die abhängigen OPTIONs schon beim ersten Response mit gesendet werden, bsw. in einem Code, der clientseitig dann als JavaScript-Array interpretiert wird. Die Nutzeraktion "Auswahl im ersten SELECT-Element" stößt dann eine clientseitige Programmlogik an, um das abhängige SELECT zu erzeugen. Es ist klar, dass der Nutzer auch während der Abarbeitung der clientseitigen Programmlogik wahrscheinlich nichts anderes tut, als zu warten. Das Asynchrone tritt bei der Kommunikation zwischen Client-Software und Server-Software auf. Die serverseitige Programmlogik hat beim ersten Response Daten mitgesendet, deren Präsentation aber nicht direkt (synchron) erfolgt, sondern von der clientseitigen Programmlogik gesteuert (asynchron) dann erfolgt, wenn diese (die clientseitige Programmlogik) es für erforderlich hält. Die serverseitige Programmlogik muss damit nicht mehr direkt auf jede Nutzeraktion reagieren. Nimmt man es ganz genau, passiert das auch bei CSS mit den dynamischen Pseudoklassen (:hover, :active, :focus). Nur kann man hier die clientseitige Programmlogik nicht selbst programmieren, man kann ihr nur Parameter liefern. Sie muss im Client dafür vorbereitet sein, dann mit diesen Parametern auf die Ereignisse der Nutzeraktionen zu reagieren.

Die Ajax-Erweiterung besteht nun darin, der clientseitigen Programmlogik auch noch die Möglichkeit zu bieten, selbständig, ohne Nutzeraktion, bei der serverseitigen Programmlogik nachzufragen, wenn es für sie erforderlich ist, oder der serverseitigen Programmlogik auch ohne direkte Nutzeraktion Daten (per HTTP-POST-Request) zu übergeben. Hier kommt also noch diese Asynchronizität hinzu, womit es folgende gibt:

(1) Nutzeraktion(Erstrequest) - Server liefert Daten, die nicht alle direkt präsentiert werden - Nutzeraktion - Client präsentiert Daten, die vom Server bereits geliefert wurden, ohne nochmals den Server kontaktieren zu müssen ...

(2) ... Nutzeraktion - Client präsentiert Daten, die vom Server bereits geliefert wurden - Client fordert neue Daten vom Server an, ohne dass der Nutzer das direkt merkt - Nutzeraktion - Client präsentiert Daten, die vom Server bereits geliefert wurden ...

(3) ... Nutzeraktion - Client erzeugt Formular und lässt Daten vom Nutzer eingeben - Nutzeraktion - Client präsentiert diese Daten, ohne Server-Request - Client sendet die bereits dem Nutzer präsentierten Daten der serverseitigen Programmlogik zum Speichern, ohne dass der Nutzer das direkt merkt ...

Es mag sein, dass es noch nicht viele Ajax-Anwendungen gibt, die das voll ausnutzen. Möglich ist es aber.

Nochmal zum Vergleich die Synchrone Abarbeitung:

Nutzeraktion - Client macht Request beim Server - Server sendet Response - Client präsentiert die Daten ...

Probleme bei der Umsetzung der Ajax-Idee sehe ich z.B. hier:

Für clientseitige Programme, die diese Idee voll umsetzten, wäre zunächst mal ein hoher Aufwand zu betreiben. Schließlich müssen diese Programme so intelligent programmiert sein, dass sie die Möglichkeiten voll ausnutzen. Das gilt besonders für meine Punkte (2) und (3) von weiter oben, wo quasi Hintergrundprozesse für die Datenanfrage und Datenspeicherung programmiert werden müssen. Da JavaScript kein Thread-Konzept hat, kann man das nur lösen, wenn man intelligent mit dem Event [XMLHttpRequest].onreadystatechange umgeht. Andererseits muss diese intelligente Programmlogik dann gezwungenermaßen _immer_ open source ausgeliefert werden, was wiederum einen hohen Aufwand an Kontrolle bedeutet, will man Urheberrechtsverletzungen nachweisen. Weiterhin ist wahrscheinlich auch überhaupt noch nicht geklärt, welche Schöpfungshöhen JavaScript-Code eigentlich unter welchen Bedingungen erreichen kann.

Zusätzlich ist für die Ajax-Idee JavaScript Voraussetzung. Da man eine clientseitige Programmiersprache im Internet in Browsern aber nicht voraussetzen kann, wäre _zusätzlicher_ Aufwand nötig, um Internet-Anwendungen auch ohne Ajax funktionsfähig zu halten. Ajax wäre hier, wie JavaScript im Allgemeinen, nur eine nützliche Beigabe, die aber nicht zwingend für die Funktionalität sein dürfte.

viele Grüße

Axel

[Cybaer]

Hi,

ich stimme Cheatah zu.

Die Technik ist asynchron. Ob sich das dann in einem bestimmten Anwendungsfall dann auch wirklich asynchron nutzen läßt, sei aber dahingestellt.

Man stelle sich nur folgenden Fall vor:

1. User gibt Daten ein
2. Ajax wird daraufhin aktiv
3. User gibt weitere Daten ein
4. Nach einigen Dateneingaben folgt nun eine Dateneingabe, die vom Ajax-Egebnis unterstützt wird.

Gleiches "Problem", aber der User mußte hier (i.d.R.) nicht warten.

Andere Beispiele ließen sich finden ...

Gruß, Cybaer