Was ändert htmx 4.0 für Ihre Web-Frontends?

htmx 4.0 ist da: Schluss mit der stillen Attributvererbung

Michael Dobler

Autor Dr. Web

29. August 2026

3 Min. Lesezeit

htmx 4.0 beseitigt die häufigste Stolperfalle der Bibliothek, die stille Vererbung von Attributen. Nach acht Monaten Arbeit ersetzt die neue Version XMLHttpRequest durch die fetch-API und holt Streaming-HTML sowie ein Morphing-Verfahren in den Kern. Vor der Migration älterer Projekte empfiehlt sich der mitgelieferte Upgrade-Check.

drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen

htmx 4.0 ist seit dem 28. August verfügbar und bricht bewusst mit einer Gewohnheit aus zehn Jahren Frontend-Entwicklung. Bisher vererbten sich Attribute wie hx-confirm oder hx-target stillschweigend an alle Kindelemente, was auf großen Seiten schwer auffindbare Nebenwirkungen auslöste. Genau diese Vererbung greift jetzt nur noch auf ausdrückliche Anforderung.

Das Wichtigste in Kürze

Attribute vererben sich nicht mehr automatisch, sondern nur mit dem Suffix :inherited oder per Konfigurationsschalter.
Der Kern nutzt statt XMLHttpRequest die fetch-API und öffnet damit die Tür zu Streaming-HTML.
Das Morphing-Verfahren idiomorph steckt jetzt fest in htmx, ohne separate Erweiterung.
Auf npm bleibt Version 2.x bis 2027 die Standardausgabe, htmx 4.0 läuft vorerst unter dem Tag next.

Was ändert sich an der Attributvererbung?

Papierflieger mit Code fliegt über Metallkoffer mit „Framework“-Label auf weißem Grund — htmx 4.0 beendet die automatische Vererbung von hx-confirm. Das :inherited-Suffix reaktiviert das alte Verhalten bei Bedarf

Die stille Vererbung galt zehn Jahre als praktisch und verwirrte Einsteiger doch am häufigsten. Ein hx-confirm am Container wirkte automatisch auf jeden Button darunter, auch dort, wo niemand eine Rückfrage wollte. Mit htmx 4.0 endet dieser Automatismus. Für das alte Verhalten hängen Sie an das jeweilige Attribut das Suffix :inherited oder stellen per Konfigurationsvariable auf den früheren Modus zurück.^[1]

Warum der Wechsel auf fetch?

Der eigentliche Umbau sitzt tiefer im Maschinenraum. htmx setzte seit der ersten Version auf XMLHttpRequest, eine Schnittstelle aus der Frühzeit von Ajax. Der Wechsel auf fetch verschlankt den Code und erlaubt vor allem Streaming-HTML, bei dem der Server Teilantworten schickt und der Browser sie sofort einsetzt.

Ein zweiter Gewinn betrifft die Chronik im Browser. Das localStorage-Caching galt laut Projekt als eine der größten Quellen für Support-Fälle und fliegt nun raus. Der Zurück-Button lädt die Seite neu und tauscht sie in den Body, sodass fremde Skripte nach der Rückkehr sauber weiterlaufen.^[1]

htmx 4.0 auf einen Blick

Die wichtigsten Eckdaten der neuen Hauptversion vom 28. August 2026

8 Monate

Entwicklungszeit bis zum Release

~16 KB

Größe minifiziert und gzip-komprimiert

fetch

ersetzt XMLHttpRequest und bringt Streaming-HTML

:inherited

Attributvererbung nur noch auf ausdrückliche Anforderung

2.x bis 2027

bleibt auf npm die Standardausgabe (Tag latest)

htmx 4.0 macht die unsichtbare Vererbung sichtbar, und genau das entscheidet, ob ein Frontend nach zwei Jahren noch wartbar bleibt. Der bewusst langsame Wechsel auf npm zeigt zudem mehr Respekt vor den Nutzern als vor dem eigenen Versionssprung.
— Markus Seyfferth, Chefredakteur Dr. Web

Was heißt das für Teams im DACH-Raum?

Für Agenturen und Mittelständler mit serverseitigem Rendern sinkt der Aufwand an JavaScript-Werkzeugen spürbar. Wenige Kilobyte im Browser ersetzen einen ganzen Build-Prozess, und das passt zu den PHP- und WordPress-Backends, die den Großteil deutscher Firmenseiten antreiben. Weniger Abhängigkeiten im Browser bedeuten zugleich eine kleinere Angriffsfläche im npm-Ökosystem, ein Punkt, der unter NIS2 und wachsender Sorge um Lieferketten zählt.

Der Umstieg beginnt mit dem mitgelieferten Werkzeug: npx [email protected] upgrade-check markiert im Bestand die geänderten Attribute, die umbenannten Events und die neue Vererbungslogik. Produktive Projekte bleiben besser auf 2.x, solange die eingebundene CDN-URL keine feste Version nennt, sonst zieht der nächste Deploy den Sprung ungefragt nach. Ein kurzer Test des Zurück-Buttons gehört ebenfalls dazu, weil fremde Skripte nach dem Umbau anders neu laden.

Eile besteht nicht. htmx 2.x erhält auf unbestimmte Zeit weiter Pflege, und der Sprung auf 4.0 lohnt erst, sobald Streaming-HTML oder das eingebaute Morphing echten Mehrwert bringen. Bis dahin genügt der Upgrade-Check als nüchterne Bestandsaufnahme.

FAQ: htmx 4.0

Muss ich sofort auf htmx 4.0 umsteigen?

Nein. htmx 2.x erhält auf unbestimmte Zeit weiter Sicherheits- und Fehlerkorrekturen, ein erzwungener Wechsel steht nicht an. Der Umstieg lohnt vor allem, sobald Sie Streaming-HTML oder das eingebaute Morphing nutzen wollen.

Wie migriere ich ein bestehendes htmx-Projekt?

Der Befehl npx [email protected] upgrade-check prüft den Bestand und markiert geänderte Attribute, umbenannte Events und die neue Vererbungslogik. Anschließend passen Sie die betroffenen Stellen an und ergänzen bei Bedarf das Suffix :inherited.

Was ändert sich beim Zurück-Button?

htmx 4.0 entfernt das localStorage-Caching und lädt beim Zurückgehen die Seite neu in den Body. Dadurch laufen fremde Skripte nach der Rückkehr korrekt weiter, während die alte Zwischenspeicherung häufig zu Anzeigefehlern führte.

Warum steht htmx 4.0 auf npm nicht als latest?

Das Team hält Version 2.x bis 2027 bewusst als Standardausgabe und veröffentlicht 4.0 zunächst unter dem Tag next. So aktualisiert niemand ungewollt über eine CDN-URL ohne feste Versionsnummer auf die neue Hauptversion.