Die Antwort darauf geben vier Buchstaben – AJAX. Jeder JavaScript-Entwickler kennt es, die meisten nutzen es auch fleißig für jede Menge Webanwendungen, die ohne ein einziges Neuladen der Seite auskommen. Für die, die es nicht kennen: Mit AJAX [1] kann man per JavaScript eine Anfrage an den Webserver stellen und den Inhalt der aktuellen Seite manipulieren, ohne dass der Browser die Seite neu laden müsste.

Ein Beispiel hierfür ist das Backend von TYPO3. Es lädt alle Seiten und Inhalte per AJAX, ohne dass je ein einziges Neuladen nötig wäre. Auf der einen Seite ist das praktisch, denn dadurch muss das System die Stylesheets und Scripts nur einmal laden, aber das ganze hat auch einen großen Nachteil. Schaut man sich die Adresszeile des Browsers an, so steht dort immer die gleiche URL, nämlich: „http://www.example.de/typo3/backend.php“.

Warum ist das ein Nachteil? Die URL ist dazu gedacht, um jeder Seite eine eindeutige Adresse zu geben. Nur so kann der Anwender die Seite per URL in den Lesezeichen speichern oder per E-Mail verschicken. Als einfache Regel kann man definieren: Wenn der Nutzer die URL aus der Adresszeile kopiert und in einem neuen Tab öffnet, muss das Angezeigte identisch sein. Doch kopiert man bei TYPO3 irgendwo im Backend die URL und versendet sie per E-Mail, landet der Empfänger nicht auf der Seite, die ihm der Sender eigentlich zeigen wollte, sondern auf der Startseite des Backends.

Ein weiteres Problem ist, dass der Browser durch die AJAX-Aufrufe nichts im Verlauf speichert, der Zurück-Button wird also nutzlos. Diese beiden Probleme kann man als Entwickler jetzt mit der HTML5 History API [2] beseitigen.

Wie das funktioniert, kann man sich in jedem Facebook-Album ansehen. Vergrößert man ein Bild, erscheinen kleine Pfeile, mit denen man zum nächsten Bild springen kann. Bei einem Klick auf diese Pfeile lädt die Seite aber nicht neu, nur das Bild ändert sich. Klickt man auf den Zurück-Knopf des Browsers, gelangt man wieder zurück zum alten Bild – wieder ohne ein Neuladen der Seite. Was wir hier sehen, ist die History API in Aktion.

Bei einem Klick auf die Pfeile lädt AJAX das neue Bild und der Aufruf „history.pushState(null, null, ’neue URL‘);“ schreibt eine neue URL in die Adresszeile sowie die alte URL in den Browser-Verlauf. Betätigt der Nutzer den Zurück-Button, löst der Browser das Event „popState“ aus, wenn die letzte URL mit pushState eingefügt wurde. Wird dieses Event ausgelöst, muss AJAX das alte Foto laden, der Browser ändert die URL in der Adresszeile automatisch.

Was ist also dran an der HTML5 History API? Sollte jeder Entwickler sofort anfangen, sie exzessiv zu nutzen? Jein, denn nicht jede Browser-Version unterstützt die History-API. Firefox [3] hat die API beispielsweise in die Version 4.0 integriert, in den meisten anderen Browsern funktioniert sie auch schon, einzig der Internet Explorer unterstützt sie noch nicht (siehe http://caniuse.com). Wenn man also jetzt schon die HTML5 History API nutzen will, sollte man unbedingt darauf achten, eine Alternative anzubieten [4].

Insgesamt überwiegen aber die Verbesserungen und Vorteile, die sich aus der Nutzung der API ergeben. Facebook macht es mal wieder vor und viele Webanwendungen werden nachziehen – die HTML5 History API ist ein riesiger Schritt in Richtung der Nutzerfreundlichkeit und löst ein Problem, das JavaScript-Entwickler schon seit langem geplagt hat.