© 2006 Tim Baumgarten
Der Euphorie die Ajax verursacht hat, stehen auch kritische
Stimmen gegenüber.
Neben normaler Skepsis die wohl allem Neuen gegenüber besteht, gibt es auch
reale Probleme die es zu lösen gilt. Erst dann wird Ajax
vermehrt in umfangreichen Anwendungen statt nur in Beispielen zu sehen sein.
Vielfach wird als KO-Kriterium angeführt, dass ein ein aktueller Browser
Voraussetzung ist und Benutzer älterer Versionen ausgeschlossen werden. Da
aber spätestens seit 2002 jeder erschienene Browser die für Ajax
benötigten Funktionalitäten mitbringt, kann man dieses Argument eigentlich
nur noch in Ausnahmefällen gelten lassen.
Im Folgenden sind einige weitere Problempunkte aufgeführt:
Obwohl sich der Begriff Ajax inzwischen weitestgehend durchgesetzt hat, ist auch der Name an sich in der Kritik. Viele halten den Namen für schlecht gewählt da wesentliche namensgebende Bestandteile für das Konzept hinter Ajax gar nicht notwendig bzw. austauschbar sind und der wichtigste Baustein XHR nichtmal explizit erwähnt wird. Ajax ist weder auf XML noch auf Javascript noch zwingend auf Asynchronität festgelegt.
So wundert es nicht das es einige Alternativvorschläge gibt, die sich aber wohl nicht mehr einbürgern werden. Ein paar Beispiele sind:
JavaScript, die Komponente die alle Teile von Ajax zusammenhält, kann
obwohl in allen aktuellen Browsern vorhanden, aus diversen Gründen
deaktiviert worden sein. Es hängt dann von der Website ab ob sich diese
dann trotzdem noch verwenden lässt. Um Benutzer ohne JavaScript nicht
auszuschließen sollten im Idealfall zumindest die Grundfunktionen auch ohne
JavaScript zur Verfügung stehen. Ist JavaScript dann doch aktiviert, lassen
sich die vorhandenen Funktionen ohne Probleme erweitern. Eine ähnliche
Möglichkeit bieten <noscript>-Tags, deren Inhalt vom Browser nicht
verarbeitet wird wenn JavaScript aktiviert ist.
In eine ähnliche Richtung geht die Kritik bzgl. mangelnder Barrierefreiheit. Sind alle Funktionen nur mit JavaScript verfügbar, kann kein Screenreader etwas mit einer Seite anfangen. Auch hier liegt es am Betreiber Alternativen zu bieten die ohne JavaScript funktionieren. Desweiteren sind Ajax bzw. DHTML Anwendungen meistens nur mit der Maus bedienbar, hier sollte man darauf achten eine Steuerung durch die Tastatur nicht unnötig zu erschweren bzw. erst zu ermöglichen.
Der Zurückbutton eines Browsers funktioniert im allgemeinen nur mit einer Abfolge von nacheinander geladenen Seiten. Wird hingegen auf einer Seite der Inhalt durch Ajax ausgetauscht, wird der Mechanismus der Browsernavigationsbuttons umgangen. Sollte der Zurückbutton trotzdem benutzt werden, hat dies meistens nicht den gewünschten Effekt.
Will ein Benutzer für eine Seite und deren aktuellen Inhalt ein Lesezeichen erstellen oder diese jemand anderem zukommen lassen treten ähnliche Probleme auf. Da sich beim Benutzen der Seite die URL nicht ändert, kommt bei einem Aufruf des Links oder des Lesezeichens nur die Startseite bzw. der Startzustand weil der eigentlich gewünschte Inhalt erst durch Interaktion des Users mit der Seite angezeigt wird.
Einen Lösungsansatz für diese Problematik basiert darauf den Fragmentbezeichner (der Teil hinter dem #) einer URL nicht als klassische Sprungmarke sondern als eine Inhaltsadresse bzw. Zustandsanzeiger zu benutzen. Dadurch das während der Benutzung gleichzeitig die URL angepasst wird, funktioniert ein Bookmarken und in den meisten Browsern auch der Zurückbutton wieder. (Eine ausführliche Beschreibung dazu gibt es unter anderem in diesem Artikel.)
Das gleiche Problem gibt es mit Suchmaschinen, sind Inhalte nicht innerhalb des HTML Dokumentes verlinkt und dementsprechend über direkte URLs erreichbar, ist für Suchmaschine das Indizieren unmöglich. In diesem Fall hilft auch der Fragmentbezeichner nicht weiter, daher muss man, will man gefunden werden, alle Inhalte auch ohne Ajax erreichbar und verlinkt bereitstellen.