Dem Reiz, mit Hilfe von Ajax mehr Funktionalität in der Client-Programmierung abzubilden, steht das unbefriedigende Angebot an Entwicklungs- und Testwerkzeugen gegenüber. Schwierige Fehlersuche Das Debugging findet in der Regel auf der untersten Tool-Ebene mit Javascript-Loggern als Browser-Plug-ins, HTTP-Sniffern und eigenen Statusausgaben statt. Best-Practice-Ansätze und Patterns für Javascript stecken gleichermaßen in den Kinderschuhen. Eine zusätzliche Schwierigkeit bei der Fehlersuche besteht in der engen Verzahnung von Javascript-Code und Server-seitigen Prozessen. Browser-Erweiterungen wie Mozilla Firebug und Ajax-Frameworks wie das Google Web Toolkit unterstützen das Debugging im Wechselspiel zwischen Client und Server.
 |
Trotz ECMA-Standard weisen die Javascript-Implementierungen verschiedener Web-Browser subtile Unterschiede auf. Zu bedenken ist, dass eines der Kernkonstrukte von Ajax, das XMLHttpRequest-Objekt, nicht Teil der Javascript-Spezifikation ist und sich in seiner Ausgestaltung von Browser zu Browser verändern kann. Der Einsatz von Bibliotheken wie Dojo vereinfacht die Ajax-Programmierung ebenso, wie Project jMaki und Java Server Faces (JSF) die Details von Javascript vor Java-Entwicklern abschotten. Microsoft bietet mit ASP.NET Ajax ein ähnliches Komponenten-Framework.
Klassische Softwaremetriken und Entwicklungsprozesse sind auf Ajax-Scripting nur bedingt abbildbar. Tief im Javascript-Code untergebrachte, asynchrone Server-Aufrufe über XMLHttpRequest sind für die meisten Tools unsichtbar. Dasselbe gilt für die Überwachung von Ajax-Anwendungen im Betrieb. Das diesbezügliche System-Management muss mit Bordmitteln realisiert werden.
Als eigentliche Auslöser für den Einsatz von Ajax verdienen Usability und das Design von Anwenderoberflächen ein besonderes Augenmerk. Zunächst ist zu beachten, dass Single-Page-Anwendungen, wie sie mit Ajax üblich sind, eigentlich keine Browser-Historie und keine Lesezeichen kennen. Das Seite-für-Seite-Navigieren wird durch eine Interaktion und Navigation innerhalb einer einzigen Web-Seite ersetzt, so dass der Back-Button des Web-Browsers ins Leere zeigt. Tatsächlich haben zahlreiche verfügbare Ajax-Frameworks solche Stolpersteine behoben.
Das "next big thing" für Web-Anwender ist in der Regel auch das jeweils neueste Einfallstor für Malware und Hacker. Dasselbe gilt auch für Ajax.
Entblößung von Web-Services
Mit der Zunahme an Ajax-Projekten werden immer mehr Unternehmens-Backend-APIs zu Web-Service-Methoden umfunktioniert. Einige dieser Methoden sind öffentlicher Natur, andere wiederum nur für den Aufruf durch interne Anwendungen gedacht. Durch den Client-seitigen Einsatz von Javascript liegt der aufrufende Code für jedermann sichtbar offen. Es ist daher unerlässlich, den Ursprung von Ajax-Aufrufen Server-seitig zu validieren und eine Ausführung nur unter definierten Bedingungen zuzulassen.
Übermäßiges Vertrauen in Javascript
Zahlreiche Web-Anwendungen verwenden Javascript, um dem Anwender Schranken aufzuerlegen, beispielsweise die Einsicht in den Quellcode-Aufruf zu verhindern, Administrator-Menüs zu verstecken, Eingaben auf Plausibilität zu prüfen sowie Benutzerrechte im Browser zu "speichern". Nichts davon ist sicher und sollte als Grundlage für sicherheitsrelevante Prozesse dienen.
Die Qual der Wahl hat man hinsichtlich der zahlreichen denkbaren Funktionen, Darstellungsformen und visuellen Elemente, die Ajax möglich macht. Bereiche einer Web-Seite lassen sich dynamisch nachladen und aktualisieren, verändern, unsichtbar machen, verschieben und verkleinern. Doch nicht alles Machbare ist in der Praxis auch sinnvoll. Es zeigt sich, dass viele Unternehmen ihre Corporate-Design-Guides um ein Kapitel über interaktive Web-Anwendungen erweitern müssen. Agenturen fehlt jedoch in der Regel das technische Know-how, um zu definieren, was von der Infrastruktur her adäquat und in der Praxis sinnvoll ist. Ohne Mitwirkung der Unternehmens-IT ist dies kaum zu meistern. (ue)
