Die kuriosesten APIs der Web-Geschichte – und was sie uns über Tech-Entscheidungen verraten
Das Geheimnis des nutzlosen Parameters: Warum das Web keine alten Seiten bricht
Stell dir mal folgendes Szenario vor: Du schreibst Code, übergibst einen Parameter – und er wird komplett ignoriert. Kein Fehler, keine Warnung, einfach weg.
Klingt absurd? Willkommen in der Welt der Web APIs.
Der berüchtigte pushState()
Als Frontend-Entwickler kennst du probably canPlayType() – diese Methode, die "probably", "maybe" oder einen leeren String zurückgibt. Aber es gibt eine API, die das Faible des Webs für Abwärtskompatibilität wirklich auf die Spitze treibt: History.pushState().
Die Funktion erwartet drei Parameter: state, title und url. Zwei davon machen Sinn:
- Das
state-Objekt speichert Daten, die beim Klick auf "Zurück" wiederhergestellt werden können. - Die
urlaktualisiert die Adressleiste – ohne Page Reload, perfekt für SPAs.
Und dann ist da noch dieser title. Der wird einfach... ignoriert. Von jedem Browser, jeder Version, kommentarlos.
Warum existiert er dann überhaupt?
Im Jahr 2008 sah die Sache noch vernünftig aus. Die Idee war: Apps könnten für jeden History-Eintrag einen eigenen Titel setzen. Stell dir vor, deine App zeigt "Dashboard" im Tab, aber in der Browser-History steht "Analytics Report". Praktisch, oder?
Naja, dachten sich die Browser-Hersteller – probably nicht. Was passiert, wenn jemand so einen Eintrag bookmarkt und der Titel nicht zum aktuellen Tab passt? Chaos.
Also beschlossen die Browser kurzerhand: Wir ignorieren den Parameter. Punkt.
Das Problem: Zu spät
Doch zu dem Zeitpunkt hatten schon unzählige Websites ihre Apps mit drei Parametern gebaut. Den dritten Parameter entfernen? Würde Produktivseiten zerstören. Optional machen? Würde bestehende pushState(state, url)-Aufrufe durcheinanderbringen.
Die Lösung war elegant: Der Parameter wurde kurzerhand in unused umbenannt und dokumentiert, dass er keinerlei Wirkung hat.
Und genau das ist das Herzstück des Webs: Abwärtskompatibilität über fast allem.
Was bedeutet das für dein nächstes Projekt?
Diese Philosophie erklärt, warum wir bei NameOcean stark auf statische Seiten und bewährte Web-Technologien setzen. Wenn du etwas baust, das lange halten soll – sei es ein Medienarchiv, eine Dokumentation oder eine Landing Page – dann ist die Stabilität von Vanilla Webtechnologie kein Nachteil. Sie ist ein Feature.
Genauso solltest du bei der Wahl deines Domain Registrars oder Hosting Providers auf Firmen setzen, die das langfristige Spiel verstehen. Das Web bleibt. Die Technologien, die du heute nutzt, sollten auch in zehn Jahren noch funktionieren.
Die Lektion
Manchmal wird eine "falsche" Entscheidung permanent – nicht weil sie richtig ist, sondern weil zu viel davon abhängt.
Das ist kein Bug im Web. Das ist das Feature, das Millionen von Seiten am Laufen hält.
Wenn du also das nächste Mal auf eine kuriose API oder einen deprecated Parameter triffst, denk daran: Irgendjemand hat vor Jahren eine Entscheidung getroffen, und jetzt ist sie tief in die Grundlagen des Webs eingebrannt.
Respektiere das Chaos. Es hält alles am Laufen.