Informationen zu Risiken und Nebenwirkungen – darum geht's hier an dieser Stelle. Nicht, um AJAX in ein schlechtes Licht zu rücken, sondern um zu einem "richtigen" Gebrauch von AJAX zu raten. Ihr Kunde verlangt eine AJAX-Anwendung und hat in seinem Unternehmen eine Hardwareausstattung aus den späten 90ern? Vergessen Sie's! Wenn die Regel nicht lautet "Pentium IV, 1 GHz, 256 MB" als Minimalausstattung, dann wird die Projektabnahme eine zähe Veranstaltung. Interaktivität im Browser hat eben ihren Preis, schließlich werkelt AJAX nicht auf Basis von Maschinencode, sondern bedient sich mit JavaScript einer Programmiersprache mit doch "stark interpretierendem" Charakter - und das Rendering von Pixeln geschieht auf Basis von HTML-Definitionen.

Ein kleines, aber wichtiges Detail
Machen Sie sich frühzeitig ein Bild über die Cache-Konfiguration des Browsers beim Kunden. AJAX-Programme leben davon, dass sie einmal "gezogen“" werden und dann im Browser des Clients geparkt werden und somit ein erneutes Laden nur bei Änderung des Programms von Nöten ist. Ein oft gesehenes Szenario: Bei der Entwicklung wird rein in einer HTTP-Umgebung gearbeitet, im Produktivsystem wird auf HTTPS geschaltet, was zunächst ja gar kein Problem ist. Da gibt es aber ein kleines, unscheinbares Flag im Browser, das besagt, dass unter HTTPS kein Caching von Seiten stattfindet. Und dieses Flag ist im Bankenbereich recht oft angeschaltet. Zur Beruhigung: In der Default Konfiguration der Browsers ist es abgeschaltet.

Ach ja, fast vergesse ich es: Weiß der Kunde, dass die JavaScript-Nutzung überall in den Browsern angeschaltet sein sollte? Auch hier gibt es oft Überraschungen kurz vor Projektende. Der AJAX-fordernde Kunde lernt auch erst im Laufe des Projektes, wie seine Infrastruktur auf AJAX vorbereitet ist.

Die Browser-Vielfalt
Die Anwendung soll interaktiv sein und gleichzeitig alle Benutzer im Internet erreichen, von Netscape 4.7 über IE 5.0 bis zu diversen Linux-Browsern? Nun ja, das geht auch nur theoretisch - mit einem HTML-Browser ohne Up-to-date-JavaScript/DOM-Unterstützung kann man eben keine Bäume ausreißen. Andersherum: Der Einsatz von AJAX im Intranet mit homogenen Infrastrukturen macht Spaß - je "internettiger" es wird, desto mehr wiegt das Argument der Browser-Vielfalt. Handelt es sich bei der Anwendung um eine komplett neue Anwendung, dann ist schnell allen klar, dass das nur mit aktuellem Browser funktioniert. Handelt es sich jedoch um eine Ersetzung bekannter Systeme (z.B. Shopping-Systeme), so steht die folgende Frage im Vordergrund: Wie viel Prozent meiner Kundschaft schließe ich durch die Forderung nach einem aktuellen Browser aus?

Die Wahl des Frameworks
Dann:: Eine direkte Programmierung auf Basis von JavaScript und HTML ist nur etwas für alle, die es sich leisten können. Oder wollen. Entweder Sie haben in Ihrer Entwicklung eine eigene Framework-Truppe, die den Umgang mit dem Browser etwas strukturiert, oder Sie müssen sich Frameworks anderer anschließen, ob kommerziellen oder open source geprägten. - Stellen Sie sich vor Sie bauen ein Java-GUI ohne Swing oder Eclipse SWT: Würden Sie nicht machen, oder?

Bitte vorher nachdenken!

Sollten Sie in Ihrer Anwendung eine doch etwas langfristigere Entwicklungsarbeit vermuten, dann machen Sie sich frühzeitig bewusst, wie viel semantische Logik Sie in JavaScript gießen wollen. Dass man Rendering-Logik in JavaScript formuliert, da gibt's keine Diskussion drüber, schließlich will man ja am Ende etwas sehen. Aber alles, was in die Richtung von Verarbeitungslogik geht, sollte kritisch beäugt werden. - Beispiel: da gibt es die Möglichkeit, vom AJAX-Client aus direkt Web Services zu rufen. Riecht erstmal gut - der Client "vorne" konsumiert diverse Services diverser Systeme "hinten". Sobald es aber ums Thema "Security" geht, beginnt man sich zu fragen, ob der Hebel an der richtigen Stelle angesetzt ist: Der Client muss nun wissen, mit welchen Credentials er sich wo anmelden muss, um überhaupt die Services konsumieren zu können. Richtig gehört: Der Client muss nun Benutzer/Kennwort kennen, um einen Web Service z.B. gegen ein SAP-System durchzuführen. - Verarbeitungslogik gehört in der Regel auf den Server, basta! Der kennt, um im Beispiel zu bleiben, so etwas wie Single-Sign-on-Konzepte.

Was ist das Gute an einem Beipackzettel? Ganz klar, dass er Ratschläge zur vernünftigen Benutzung gibt. Aber, noch wichtiger, dass es das zugehörige Medikament gibt! - Björn Müller (Software AG)

Björn Müller leitet bei der Software AG den Bereich "XMLi User Interfaces", der u.a. eine AJAX-basierte Frontend-Lösung für interaktive Unternehmensanwendungen verantwortet. Mit seiner Firma Casabac (heute Teil der Software AG) war Björn Müller einer der frühen AJAX-Pioniere in Deutschland.