Ajax ist ja seit einem guten Jahr in aller Munde, obwohl es sich, wie hier schon des öfteren angesprochen, um nix anderes als einen kombinierten Aufguss bestehender Technologien handelt.
Genauer gesagt handelt es sich bei Ajax um "Asynchronous JavaScript And XML", also Technologien, wie sie schon seit vielen Jahren zur Verfügung stehen. Genauer gesagt, spätestens seit Microsoft sein XMLHttp-Objekt für den Internet Explorer 5 bereitgestellt hat, was so etwa genau 8 (in Worten: acht) Jahre her ist.
Aber genug der Vorrede, wer mehr allgemeine Facts zu Ajax lesen möchte, kann sich die Infos zum Beispiel bei Wikipedia beschaffen. Ich will an dieser Stelle eigentlich nur mal meine subjektiv objektiv gesammelten Fakten kundtun, und darstellen, warum ich vom aktuellen Hype nichts halte, und trotzdem nicht ganz unbegeistert von der Entwicklung bin.
Pro:
- Mit Ajax lassen sich Oberflächen im Look&Feel von Desktop-Anwendungen ins Netz bringen.
- "Online-Anwendungen" bedürfen nur eines Browsers und lassen sich damit wesentlich leichter deployen. Nimmt man Firefox hat man quasi die absolute Plattformunabhängigkeit, wie sie sich mit Java nie durchsetzen konnte.
- Es kann, gerade auf High-Traffic-Anwendungen, Datenverkehr massiv vermieden werden.
Contra:
- JavaScript war schon seit den ersten Tagen eine der häufigsten Ursachen für Sicherheitslücken in Browsern, vor allem im IE, aber auch in Firefox und Opera. Es mag also nicht jeder aktivieren, und nicht jede Firma erlaubt es auf ihren Clients, oder filtert es sogar aus.
- "JavaScript-Links" sind nicht bookmark- oder kopierfähig. Dies sieht man ideal bei Google Maps - navigiert man dort an einen beliebigen Ort der Erde, kann man den aktuellen Kartenausschnitt nicht direkt einem Freund weiterleiten, in dem man die Adresse wie gewohnt aus der URL-Zeile kopiert, sondern man ist darauf angewiesen, dass der Anbieter einem diese Adresse zur Verfügung stellt. Google tut es, viele andere nicht.
So laden neuerdings viele Leute gerne die Seiteninhalte dynamisch via JavaScript in die Seite - navigiert man dann via JavaScript auf der Seite, hat man keine Chance, dass was man aktuell sieht zu bookmarken oder weiter zu geben.
- Ajax-Anwendungen sind nicht von Suchmaschinen indizierbar. Gleiches Problem wie bei den Bookmarks: Suchmaschinen können keinen "JavaScript-Links" folgen.
- Es ist nicht wirklich schneller. Zwar müssen beim teilweise Nachladen via Ajax auf einer Seite nicht die kompletten Seiteninformationen mitgeladen werden, tatsächlich liegen die aber meistens eh bereits im Browsercache bzw. sind für den Client bei den heutigen DSL-Anbindungen kein Faktor mehr. Und ob ich nun via Ajax oder direkt Inhalte von einem langsamen Server lade macht keinen Unterschied, der braucht für die Bereitstellung immer gleich lang.
- Debuggen: aus Entwicklersicht tun sich beim Debuggen von Ajax-Anwendungen neue Schwierigkeiten auf. Durch die Vermischung von Server und Client hat man nun gleich zwei Baustellen, die potentiell für auftretende Fehler verantwortlich sein können.
- JavaScript-Unterstützung unterschiedlicher Browser. Das alte Leid/Lied - die Implementierung von JavaScript hat sich zwar in den letzten Jahren zwischen den einzelnen Anbietern angeglichen, aber es gibt immer noch Unterschiede. Dies wird wohl auch in Zukunft immer so bleiben.
Fazit:
Meine derzeitige Empfehlung lautet immer: Ajax ja, aber nur unter bestimmten Voraussetzungen:
- Indizierbarkeit darf kein Kriterium sein.
- Die Clients (Browser) müssen definierbar bzw. reglementierbar sein.
Das erfüllen quasi immer nur Intranet-Anwendungen. Für Webanwendungen halte ich die Zeit noch nicht reif für Ajax, vielleicht werden die angesprochenen Probleme von den Browser- und Suchmaschinenanbietern demnächst gelöst, aber bis es soweit ist, würde ich die Finger von Ajax bei elementaren Funktionen wie Blätterfunktionen, Navigationen usw. auf öffentlichen Webseiten lassen.
Just my 2 cents.
