</> Htmx – The Fetch()ening

• htmx 4.0 ist eine umfassende Neubau-Version, die die bisherige auf XMLHttpRequest basierende Struktur vollständig durch eine auf fetch() ausgerichtete asynchrone Struktur ersetzt
• Die Vererbung von Attributen wechselt von implizit zu einer expliziten Deklaration mit :inherited, was Klarheit und Wartbarkeit des Codes verbessert
• Der History-Cache wird vereinfacht: Statt lokaler Snapshot-Speicherung erfolgt die Wiederherstellung auf Basis von Netzwerk-Requests, was die Zuverlässigkeit erhöht
• Verschiedene neue Funktionen wie Streaming-Antworten, SSE, DOM-Morphing, das <partial>-Tag und eine View-Transition-Warteschlange werden in den Core integriert
• Langfristig sind eine Vereinfachung der Codebasis und bessere Erweiterbarkeit das Ziel; bestehende 2.0-Nutzer sollen weiterhin unterstützt werden

---

Überblick über htmx 4.0

• htmx 4.0 schreibt die bestehende Struktur vollständig neu und berücksichtigt dabei die Entwicklungserfahrung mit fixi.js sowie fünf Jahre Wartungs-Erkenntnisse
• Die wichtigsten Änderungen lassen sich auf drei Kernpunkte zusammenfassen: Umstieg auf fetch(), explizite Attributvererbung und vereinfachter History-Cache

The fetch()ening

• XMLHttpRequest wird durch fetch() ersetzt und modernisiert damit die Ajax-Infrastruktur
  • Für die meisten Anwendungsfälle hat das keine großen Auswirkungen, aber das Event-Modell ändert sich entsprechend der asynchronen Eigenschaften von fetch()
• Dieser Umstieg schafft die Grundlage für einfacheren Code und künftige Funktionserweiterungen

Explizite Attributvererbung

• Statt der bisherigen impliziten Vererbung wird der Modifikator :inherited für eine explizite Deklaration verwendet
  • Beispiel:

    <div hx-target:inherited="#output">
        <button hx-post="/up">Like</button>
        <button hx-post="/down">Dislike</button>
    </div>
    

  • Wenn hx-target nicht explizit angegeben ist, wird es nicht an untergeordnete Elemente vererbt
• Für die meisten Nutzer ist das die größte Änderung beim Upgrade

Vereinfachung des History-Cache

• Der lokale DOM-Snapshot-Cache in htmx 2.0 war wegen Änderungen durch Dritte, verstecktem Zustand usw. instabil
• In 4.0 wird auf eine Wiederherstellung über Netzwerk-Requests umgestellt
  • Cache-Erweiterungen werden optional per Opt-in angeboten
• Das vereinfacht die Codebasis und erhöht die Zuverlässigkeit des Standardverhaltens

Was bestehen bleibt

• Zentrale APIs wie hx-get, hx-post, hx-target, hx-boost, hx-swap und hx-trigger bleiben unverändert
• Abgesehen von der Ergänzung um :inherited sollten die meisten Projekte mit ihrem bestehenden Code weiter funktionieren
• Langfristige Wartbarkeit und Stabilität werden gestärkt

Upgrade-Strategie

• Nutzer von 2.0 benötigen ein Upgrade-Projekt, aber 2.0 wird dauerhaft unterstützt
• 4.0 wird parallel zu 2.x ausgeliefert; der Wechsel von latest wird Anfang 2027 erwartet
• Eine Extension, die das Verhalten von 2.0 wiederherstellt, ist geplant

Überblick über neue Funktionen

Integration von Streaming-Antworten und SSE

• Mit Unterstützung für Readable Streams in fetch() sind teilweise DOM-Ersetzungen möglich
• SSE (Server Sent Events) wird wieder als Core-Feature integriert und unterstützt schrittweise Inhaltsaktualisierung

Morphing Swap

• Auf Basis des Idiomorph-Algorithmus wird beim Zusammenführen des DOM die Entscheidung über Erhalt oder Entfernung von Knoten verbessert
• morphInner- und morphOuter-Swaps sind im Core enthalten

Unterstützung für das <partial>-Tag

• Die komplexe Syntax bisheriger Out-of-band-Swaps wird vereinfacht
• <partial> ist ein Template-Element und kann Standardattribute wie hx-target und hx-swap verwenden
• Out-of-band-Swaps werden wieder auf einfache id-basierte Ersetzungen zurückgeführt

Verbesserungen bei View Transitions

• Durch Einführung einer Transition-Queue werden visuelle Konflikte vermieden
• CSS-Transitions bleiben unverändert, die asynchrone Runtime wird vereinfacht
• Ob die Funktion standardmäßig aktiviert wird, ist noch offen

Stabilisierung der Event-Reihenfolge

• Die auf fetch() basierende asynchrone Struktur erleichtert die Garantie einer stabilen Event-Reihenfolge
• Neues Schema für die Event-Benennung:
  htmx:<phase>:<system>[:<optional-sub-action>]
  • Beispiel: htmx:before:request

Mehr Erweiterbarkeit

• Auf Basis von async werden Erweiterungen für Preload und optimistische Updates bereitgestellt
• Der Request-/Response-/Swap-Zyklus wird für Extension-Entwickler geöffnet, und die fetch()-Implementierung kann ausgetauscht werden
• Gewünschtes Verhalten lässt sich ohne Hacks umsetzen

Verbesserungen bei hx-on

• Übernommen wird die standardisierte Syntax hx-on:<event name>
• Mit Unterstützung für asynchrone APIs wird einfaches DOM-Scripting möglich

  <button hx-post="/like"
          hx-on:htmx:after:swap="await timeout('3s'); ctx.newContent[0].remove()">
      Get A Response Then Remove It 3 Seconds Later
  </button>
  

• Funktioniert auch in Umgebungen mit deaktiviertem eval(), wenn auch mit einigen Einschränkungen

Gesamtausrichtung

• htmx 4.0 will ein ähnliches Nutzungserlebnis wie 2.0 beibehalten und zugleich weniger Bugs sowie bessere Funktionen bieten
• Mit vereinfachtem Code, expliziter Struktur und asynchroner Erweiterbarkeit soll htmx stabiler und moderner werden

Entwicklungszeitplan

• Die Alpha-Version (htmx@4.0.0-alpha1) ist bereits veröffentlicht
• Das offizielle Release 4.0.0 ist für Anfang bis Mitte 2026 geplant
• Anfang 2027 ist der Wechsel zu latest vorgesehen
• Den Entwicklungsstand kann man im GitHub-Branch four und unter four.htmx.org verfolgen

---

[GN⁺]

Hacker-News-Kommentare

• Man hat es sich am Ende anders überlegt und beschlossen, eine neue Major-Version von htmx zu veröffentlichen.
  Um das Versprechen einzuhalten, dass es „kein 3.0 geben wird“, heißt die nächste Version jedoch htmx 4.0.
  Dazu gab es scherzhafte Reaktionen, dass das technisch ja korrekt sei.

  • Eine witzige Lösung, aber sie könnte Nutzer verwirren wie einst das verschwundene PHP 6.
    Vielleicht wäre es besser gewesen, einfach ehrlich als 3.0 zu veröffentlichen.
  • Als Witz wurde vorgeschlagen, direkt zu htmx 4.1 zu springen und stattdessen „xhtmx 1.0“ zu bauen.
  • Es erinnere an Leisure Suit Larry 4: The Missing Floppies.
  • Zum Glück habe man nicht gesagt, „es wird keine dritte Version geben“, womit noch etwas Interpretationsspielraum bleibe.

• htmx 2.0 soll dauerhaft unterstützt werden, daher gebe es überhaupt keinen Upgrade-Druck.
  In einer Zeit, in der API-Änderungen häufig sind, sei ein solcher Ansatz lobenswert.

• Es wirke so, als würden Menschen, die Stabilität anstreben, oft die falsche Lehre ziehen.
  Statt wie bei Python 3.0 viele große Änderungen auf einmal zu bündeln, sei eine schrittweise Release-Strategie besser.
  Wenn Änderungen etwa auf 2.1, 4.0, 5.0 usw. verteilt würden, sei das deutlich einfacher zu handhaben.
  Empfohlen wird ein Ansatz wie bei Django, bei dem Kompatibilitätsphasen über mehrere Versionen hinweg erhalten bleiben.

• Die Beschreibung des Attributs hx-target wirke verwirrend.
  Statt „inherited“ erscheine „inheritable“ oder „inherit“ natürlicher.

  • Jemand meinte, er habe es so gelesen, als würde „das Kind es erben“, und schlug vor, dass etwas wie „pass-down“ klarer sein könnte.
  • „inherited“ sei das falsche Wort, „inherit“ sei kurz und gut.
    Scherzhaft wurde ergänzt, man könne auch „bequeath“ sagen.
  • Es hieß, man denke über verschiedene Formulierungen nach und sei offen für Rückmeldungen.
  • Auch Alternativen wie „heritable“ oder „cascade“ wurden vorgeschlagen.

• Die Ideen von HTMX und die Hypermedia-Philosophie seien großartig.
  Man habe sich vom SPA-Umfeld abgewandt und Datastar gewählt, weil sich die investierte Lernarbeit dort stärker in Skalierbarkeit auszahle.
  Durch das direkte Pushen von Signalen vom Server in den Browser konnte Polling-Code entfernt werden, was die Komplexität stark reduzierte.
  Auch die Abhängigkeit von Alpine.js fiel weg, wodurch der Code einfacher wurde, und Streaming-basierte Aktualisierungen kompletter Views funktionierten dank Komprimierung effizient.
  Wer aus der SPA-Welt komme, solle sowohl Datastar als auch HTMX ausprobieren.

• Der Wechsel zu fetch() zur Nutzung von Readable Stream sei interessant.
  Man habe HTMX viel verwendet, bevorzuge in letzter Zeit aber Datastar wegen seines SSE-basierten Streamings.

• Man freue sich über die Weiterentwicklung von HTMX, habe aber den Eindruck, dass Datastar eine stärker standardnahe und flexiblere API biete.
  In dem kleinen Paket steckten viele Funktionen wie Fetch, SSE, deklarative Signale und DOM-Morphing.
  Deshalb werde die Frage gestellt: „Warum sollte ich HTMX verwenden?“

  • Es wurde angemerkt, dass Datastar Pro nicht Open Source ist und dadurch ein Vertrauensrisiko bestehe.
  • Erwähnt wurde auch die Ironie, dass der Entwickler von Datastar solche Funktionen früher in HTMX unterbringen wollte.
  • Erklärt wurde, dass HTMX seine Stärke in einer einfachen Oberfläche hat, die für das Request/Response-Paradigma optimiert ist.
    Datastar sei stärker auf Event-Streams ausgerichtet und eigne sich daher gut für Echtzeit-Dashboards oder Spiele, doch für die meisten Web-Apps sei die Einfachheit von HTMX vorteilhafter.
    Dazu passend: Datastar essay, Less HTMX is More
  • HTMX unterstütze die Verwaltung der URL-Historie im Browser einfach, während Datastar diese Funktion als kostenpflichtiges Pro-Feature eingeschränkt habe.

• Es wurde spöttisch angemerkt, dass man nach der Aussage, das System sei „perfekt und brauche keine weiteren Major-Versionen“, nun doch die Notwendigkeit zur Weiterentwicklung eingestehe.
  Unter Verweis auf die Stelle „jetzt ändern wir den Standard für Event-Namen“ wurde das als Versuch satirisch kommentiert, JavaScript zu vermeiden.

  • Spöttisch hieß es, man habe am Ende doch eine benutzerdefinierte Syntax per JS interpretieren lassen, obwohl man JavaScript vermeiden wollte.
    Trotzdem wurde anerkannt, dass man damit Absichten in HTML ausdrücken kann.
  • Es wurde gewitzelt, „diesmal sei es wirklich die letzte Version“.
  • Positiv wurde aufgenommen, dass es „immer noch besser ist, als direkt JavaScript zu schreiben“.
  • Außerdem wurde der kritische Ton hinterfragt: „Was ist denn daran schlimm, dass der Autor seine Meinung geändert hat?“

• Der Artikel sei sehr klar geschrieben und vermittle viel über die Philosophie des API-Designs.

• Jemand habe xhr-fetch-proxy gebaut, um fetch und HTMX gemeinsam zu nutzen,
  und denke, dass diese Änderung noch mehr Möglichkeiten eröffnen werde.
  Projektlink

  • In 4.0 sei der Request-Zyklus vollständig geöffnet, sodass sich für jede Anfrage die fetch-Implementierung austauschen lasse.
    Diese Idee habe man von fixi.js übernommen.