Die sieben Todsünden der AJAX-Entwicklung

1. Speicherlecks: Jeder, der lange genug in der Software-Entwicklung gearbeitet hat, kennt zyklische Referenzen und die Gefahr, die sie für die Speicherverwaltung mitbringen. Javascript, das Kernstück von AJAX, ist eine Programmiersprache mit Speicherverwaltung. Das bedeutet, dass Javascript über einen eingebauten Garbage Collector verfügt, der Variablen aufspürt, die nicht mehr referenziert werden, und den entsprechenden Speicherplatz wieder freigibt.

Das ist im Allgemeinen eine feine Sache, aber man kann sich nicht darauf verlassen, dass damit der Speicher immer optimal genutzt wird. Denn es kann immer zu solchen zyklischen Referenzen kommen, zum Beispiel wenn ein Objekt der Modell-Schicht auf ein View-Element verweist und umgekehrt. Wenn man das Objekt durch Zuweisung des Wertes null löscht, wird im Prinzip auch das zugehörige Element gelöscht, es sei denn, es gibt eine Rückwärtsreferenz vom Element zum Objekt. In einem solchen Fall rührt der Garbage Collector das Objekt nicht an.

Wirklich knifflig wird die ganze Angelegenheit aber erst hier: Im Document Object Model kann jeder DOM-Knoten, der Bestandteil des Dokumentenbaumes ist, allein durch die Tatsache, dass er im Baum vorhanden ist, referenziert werden – egal, ob er von einem anderen Objekt explizit referenziert wird oder nicht! Daher muss jedes für den Garbage Collector markierte Objekt, das von einem DOM-Knoten referenziert wird, ausdrücklich in dieser Richtung gelöscht werden, sonst bleibt sein Speicher zugewiesen!

2. Nicht verstehen, was „asynchron“ bedeutet: Asynchronität kann für Benutzer reichlich verwirrend sein, wenn sie damit nicht vertraut sind. Das entbehrt nicht einer gewissen Ironie, denn die für diese Benutzer mit AJAX erstellten Webanwendungen wären für diese als normale Desktop-Anwendungen keineswegs irritierend. Das ist ein wichtiger Designaspekt! Die meisten Webanwendungen funktionieren ähnlich wie ihre Desktop-Pendants. Aber eine Webanwendung bringt ein auf den ersten Blick nicht immer erkennbares Merkmal mit, das für den entscheidenden Unterschied sorgt: die Erwartungen des Benutzers.

Benutzer bringen beim Arbeiten mit einem Webbrowser unterschiedliche Vorurteile und Erwartungen mit. Daher mag es zwar enorm cool sein, wenn im Hintergrund Unmengen von Daten zwischen Webseite und Server ausgetauscht werden, aber während die Seite aktualisiert wird, ist es für den Benutzer auch höchst irritierend, diese permanenten Änderungen beobachten zu müssen. Aus diesem Grund sollte man zwei Grundregeln anwenden und sie immer dann beachten, wenn im Blickfeld des Benutzers eine Veränderung stattfindet: Falls die Aktualisierung für den Benutzer nicht unmittelbar von Bedeutung ist, sollte sie so unauffällig wie möglich erfolgen. Aber falls die Aktualisierung für die Interaktion des Benutzers mit der Anwendung entscheidend ist, sollte sie auf der Seite deutlich und hervorgehoben stattfinden.

3. Den Server im Dunklen lassen: Das Entkoppeln von Client und Server hat einen enormen Nachteil, der nicht auf den ersten Blick offensichtlich ist. Serverseitige Anwendungen wissen alles und sehen alles: Jede Ausnahme, jeder Reload, jedes Ereignis kann beobachtet und aufgezeichnet werden. Und natürlich weiß der Server genau, wie der Client gerade aussieht, denn im Prinzip schreibt der Server alles, was auf dem Bildschirm zu sehen ist.

Bei einer AJAX-Anwendung ist all dies nicht der Fall. Es passieren Dinge völlig unabhängig vom Server, was bedeutet, dass es auf Seiten des Clients Probleme geben kann, von denen der Server nicht sofort etwas mitbekommt. Daher sollte man Ereignisse und Ausnahmen auf Clientseite erfassen und protokollieren, und zwar so, dass der Server gegebenenfalls auf diese Daten zugreifen und möglichst schnell intervenieren kann.

4. Nachlässig mit GET werden: GET dient dem Abrufen von Daten, POST für deren Festlegen. GET sollte nicht unnötig verwendet werden, auch wenn man überzeugt ist, damit keinen Schaden anzurichten. GET-Operationen ändern den Status und Links, die den Status verändern, sind für die Benutzer verwirrend. Die meisten sind an Links als Navigationshilfe gewohnt, aber nicht zum Aufrufen von Funktionen.

5. Datentypen nicht in Betracht ziehen: Javascript ist nicht Bestandteil des .NET-Frameworks. Das mag zwar für manchen betrüblich sein, liefert aber ein gutes Beispiel für ein Problem, dem sich der Programmierer womöglich gegenübersieht: Er muss sicherstellen, dass Javascript die Datentypen der Plattform versteht, auf der es läuft – und umgekehrt. Es steht eine Reihe von Konvertern zur Verfügung, die auch genutzt werden sollten. Die Ajax.NET-Pro-Library zum Beispiel bietet Konverter, die Objekte zwischen .NET und Javascript Object Notation (JSON) konvertieren können.

6. Einige Anwendungen wissen nicht, wann es genug ist: Das dynamische Erzeugen von Content, unabhängig vom Neuladen der Seite, kann fatale Folgen haben, wenn diesem kein Einhalt geboten wird. Wenn schon Webseiten, die einfach kein Ende finden, für Benutzer verwirrend sind, was sollen sie dann erst von einer Anwendung halten, die permanent läuft? Eine Webseite kann gern dynamisch gestaltet sein, aber es ist darauf zu achten, wann das Maß voll ist.

7. Javascript und DOM vermischen: AJAX funktioniert nach dem Model-View-Controller-Konzept. Dies sollte ernst genommen werden. Javascript gehört zur Model-Schicht, DOM in die View-Schicht und der Controller bringt beide zusammen. Es sollte sichergestellt sein, dass das Webdokument unabhängig von Javascript immer denselben Inhalt hat (was auch Benutzern ohne Javascript hilft). Eine Ausnahme gibt es: In manchen Fällen sind die Inhalte nur bedeutungsvoll und praktisch nutzbar, wenn sie mit Javascript verwendet werden. Nur in einem solchen Fall sollte der Content mit Javascript erstellt werden.