Der Browser ist heute häufiger selbst Teil der Lösung
Wer vor einigen Jahren eine komplexere Benutzeroberfläche bauen wollte, griff schnell zu zusätzlichem JavaScript. Modale Fenster, schwebende Menüs, auf Zustände reagierende Elemente oder aufwendigere Animationen bedeuteten häufig: Bibliothek installieren, eigenes Skript schreiben oder vorhandene Komponenten nachrüsten.
Das hat sich spürbar verändert. HTML, CSS und standardisierte Browser-APIs können inzwischen Aufgaben übernehmen, die früher wesentlich häufiger außerhalb der eigentlichen Webplattform gelöst wurden. Ein gutes Beispiel ist das HTML-Element dialog. Der Browser bringt damit eine standardisierte Grundlage für modale und nicht modale Dialogfenster mit. Die zugehörigen Funktionen sind browserübergreifend seit Jahren etabliert.
Ähnlich funktioniert die Popover API: Inhalte wie kleine Infoflächen oder schwebende Bedienelemente können standardisiert über anderen Seiteninhalten dargestellt und teilweise direkt über HTML-Attribute gesteuert werden. Das grundlegende popover-Attribut gehört seit 2024 zur browserübergreifend neu verfügbaren Baseline.
CSS kann heute stärker auf Zustände reagieren
Auch CSS selbst ist deutlich ausdrucksstärker geworden. Der Selektor :has() kann beispielsweise ein Element danach auswählen, was sich darin oder unmittelbar daneben befindet.
Das klingt zunächst nach einem Detail, verändert in der Praxis aber einiges. Eine Karte kann anders gestaltet werden, wenn sie ein bestimmtes Element enthält. Ein Formularbereich kann auf den Zustand eines enthaltenen Feldes reagieren. Für manche solcher Aufgaben musste früher per JavaScript geprüft und anschließend eine zusätzliche CSS-Klasse gesetzt werden.
:has() ist seit Dezember 2023 browserübergreifend breit verfügbar. Das bedeutet trotzdem nicht, dass damit Anwendungslogik nach CSS verlagert werden sollte. Der Selektor eignet sich für Darstellungs- und Zustandsfragen; komplexe Logik bleibt eine andere Aufgabe. Zudem weist MDN darauf hin, dass sehr breit formulierte :has()-Selektoren bei dynamischen Seiten unnötige Arbeit für den Browser verursachen können.
Genau darin zeigt sich die Entwicklung: Nicht JavaScript verschwindet. Bestimmte kleine Hilfsskripte werden schlicht überflüssig, weil die Plattform die benötigte Funktion inzwischen selbst kennt.
Animationen rücken näher an den Browser
Ein ähnlicher Wandel findet bei Animationen statt. Klassische CSS-Animationen und Transitions sind längst etabliert. Neuere Ansätze gehen weiter und können Bewegungen unmittelbar mit dem Scrollfortschritt einer Seite oder eines Elements verknüpfen.
Die sogenannten CSS Scroll-Driven Animations verwenden dafür eine scrollbasierte statt einer rein zeitbasierten Animationszeitleiste. Ein Fortschrittsindikator, eine dezente Einblendung oder eine Bewegung entlang des Seitenverlaufs kann dadurch in passenden Fällen ohne selbst programmierte Scroll-Handler umgesetzt werden.
Für produktive Projekte ist allerdings noch Vorsicht nötig: Zentrale Eigenschaften wie animation-timeline gelten im August 2026 weiterhin als nicht Baseline, weil sie noch nicht in allen wichtigen Browsern verfügbar sind. Selbst web.dev musste im April 2026 eine zuvor zu optimistische Baseline-Einordnung einzelner Scroll-Animation-Funktionen wieder korrigieren.
Die Technik ist damit interessant, aber ein gutes Beispiel dafür, warum „moderner Webstandard“ nicht automatisch „überall problemlos einsetzbar“ bedeutet.
View Transitions sollen Orientierung schaffen
Die View Transition API setzt an einer anderen Stelle an. Sie unterstützt flüssige Übergänge zwischen unterschiedlichen Zuständen einer Oberfläche und inzwischen auch zwischen Dokumenten. Der Browser kann dabei alte und neue Ansichten erfassen und den Wechsel animieren, anstatt dass Entwickler die gesamte Übergangslogik selbst nachbauen müssen.
Für Übergänge innerhalb desselben Dokuments ist document.startViewTransition() seit Oktober 2025 Baseline und damit auf aktuellen Browsergenerationen browserübergreifend verfügbar. Vollständige seitenübergreifende View Transitions sind dagegen noch nicht auf demselben Stand: Das dafür wichtige CSS-@view-transition wird von MDN weiterhin mit eingeschränkter Verfügbarkeit geführt.
Auch hier geht es nicht darum, jede Navigation mit Bewegung auszustatten. Gute Übergänge können verdeutlichen, wo ein Element geblieben ist oder wie zwei Ansichten zusammenhängen. Eine dauerhaft herumfliegende Oberfläche erzeugt dagegen eher Unruhe.
Deshalb gehört zur modernen Animation ebenso, die Nutzereinstellung prefers-reduced-motion zu respektieren. Sie ist seit 2020 breit verfügbar und signalisiert, wenn nicht notwendige Bewegung reduziert oder ersetzt werden sollte.
Responsive Design denkt stärker in Komponenten
Lange bedeutete Responsive Design vor allem: Wie breit ist das Browserfenster? Media Queries beantworten genau solche Fragen und bleiben dafür unverzichtbar.
[Container Queries](https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Containment/Container_queries) ergänzen diese Logik um eine andere Perspektive. Eine Komponente kann sich danach richten, wie viel Platz ihr **innerhalb ihres eigenen Containers** zur Verfügung steht.
Eine Artikelkarte könnte beispielsweise in einer schmalen Seitenleiste kompakt untereinander aufgebaut sein und im breiten Inhaltsbereich Bild und Text nebeneinander zeigen – obwohl sich die Größe des Browserfensters überhaupt nicht verändert hat.
Für modulare Websites ist das besonders hilfreich: Komponenten müssen weniger darüber wissen, an welcher Stelle der Seite sie eingesetzt werden. Die zentralen Container-Query-Funktionen sind seit Februar 2023 breit browserübergreifend verfügbar.
Weniger Abhängigkeiten können ein Vorteil sein
Wenn der Browser eine Aufgabe zuverlässig selbst übernimmt, kann es sinnvoll sein, auf eine zusätzliche Bibliothek oder eine eigene Hilfslösung zu verzichten. Weniger Abhängigkeiten bedeuten potenziell weniger Pakete, die aktualisiert, überwacht und bei Änderungen angepasst werden müssen. Auch zusätzlicher JavaScript-Code, der für eine einfache Standardfunktion geladen und ausgeführt werden müsste, kann entfallen.
Daraus folgt allerdings keine einfache Formel nach dem Motto „nativ ist immer schneller“. Die Performance einer Website hängt von vielen Faktoren ab: Architektur, Bilder, Schriftarten, Rendering, Datenmengen, Drittanbieter-Skripte und die konkrete Umsetzung spielen häufig eine größere Rolle als die Frage, ob für eine einzelne Funktion eine Bibliothek verwendet wird.
Auch Frameworks werden dadurch nicht überflüssig. Bei umfangreichen Webanwendungen helfen sie weiterhin dabei, komplexe Zustände, Datenflüsse, Komponenten und Anwendungslogik zu strukturieren.
Die sinnvollere Frage lautet deshalb nicht: Wie bekommen wir JavaScript aus der Website? Sondern: Brauchen wir für diese konkrete Aufgabe wirklich noch eine zusätzliche technische Schicht?
Modern heißt auch: mit unterschiedlichen Browsern rechnen
Die unterschiedlichen Reifegrade der genannten Funktionen zeigen, warum Browserunterstützung weiterhin Teil guter Frontend-Arbeit ist. Während dialog, :has() und grundlegende Container Queries längst breit einsetzbar sind, befinden sich andere Möglichkeiten noch in einer Übergangsphase.
Hilfreich ist dabei das Konzept des Progressive Enhancement: Die grundlegende Website funktioniert zunächst mit robusten, etablierten Techniken. Neuere Funktionen verbessern anschließend das Erlebnis in Browsern, die sie beherrschen. Fällt beispielsweise eine optionale Animation weg, müssen Navigation und Inhalte trotzdem nutzbar bleiben.
CSS bietet mit @supports zudem eine etablierte Möglichkeit, Unterstützung bestimmter CSS-Funktionen gezielt abzufragen. Für einen schnellen Überblick über die browserübergreifende Reife einer Webfunktion hilft außerdem die Baseline-Kennzeichnung in technischen Dokumentationen.
Weniger Zusatzcode funktioniert also am besten zusammen mit einer weiterhin nüchternen Prüfung dessen, was reale Geräte und Browser tatsächlich können.
Weniger Ballast statt weniger Webentwicklung
Moderne Websites werden nicht technikfrei – im Gegenteil: Die Webplattform selbst wird technisch leistungsfähiger.
Der entscheidende Unterschied liegt darin, wo bestimmte Funktionen umgesetzt werden. Dialoge, Popovers, komplexere CSS-Zustände, komponentenbezogene Layouts und zunehmend auch Übergänge oder Animationen müssen nicht mehr zwangsläufig durch zusätzliche Bibliotheken und individuell gebaute Workarounds entstehen.
Das kann Websites übersichtlicher und langfristig leichter wartbar machen. JavaScript, Frameworks und Bibliotheken behalten trotzdem ihren Platz überall dort, wo sie echte Aufgaben lösen.
Modernes Frontend bedeutet deshalb zunehmend, die Möglichkeiten des Browsers zuerst zu kennen – und zusätzliche Technik gezielt dort einzusetzen, wo sie tatsächlich gebraucht wird.
Kommentare
Moderierte Rückmeldungen
Kommentare erscheinen erst nach Prüfung. E-Mail-Adressen werden nicht veröffentlicht.