HTMX war so cool, dass ich es selbst gebaut habe (2024)

• HTMX ist ein Ansatz, der servergerendertes HTML in den Mittelpunkt stellt und das Frontend schrittweise verbessert; er entwickelt die Arbeitsweise weiter, die vor dem Aufblähen moderner JavaScript-UIs im React-Stil verbreitet war
• Beim Refactoring des Servers einer selbst gehosteten Podcast-Web-App wurde SvelteKit durch DinoSsr ersetzt, wodurch das Problem entstand, dass Seitenwechsel die Audiowiedergabe unterbrachen; mit HTMX ließ sich nur der ``-Bereich aktualisieren, sodass die Audio-Komponente erhalten blieb
• HTMX wird zwar als Frontend-Bibliothek ausgeliefert, ein großer Teil der Implementierung liegt aber in Backend-Templates und der Serverkonfiguration; HTTP-Anfragen, die HTML zurückgeben, fungieren praktisch als HTMX-API
• hx-*-Attribute, ein anklickbares ``-Beispiel und fortgeschrittene Beispiele mit viel Inline-JavaScript zeigen die Grenzen deklarativer Attribut-Templates und gehören zu den Kritikpunkten an der Dokumentation
• Die selbst gebaute Mini-Implementierung nutzte 304-Caching, die History API, das Ersetzen von `` sowie Pointer-Event-basiertes Preloading als Kernelemente und führte mit weniger Browser-JavaScript zu einer kleineren und einfacheren Codebasis

---

Die Stellung von HTMX

• HTMX lehnt modernes JavaScript für UIs ab, bevorzugt servergerendertes HTML und entwickelt einen Ansatz weiter, der aus der Zeit vor dem aufgeblähten React-Frontend stammt
• Unendliches Scrollen und Live-Suchergebnisse sind beliebte HTMX-Beispiele; HTMX löst nicht alle Probleme, die React und ähnliche Tools angehen, und wirkt dadurch begrenzt, ist aber innerhalb dieser Grenzen ein sehr wertvolles Werkzeug
• HTMX ist kein „magic bullet“, und ein zentraler Punkt ist die Sichtweise, dass manche Ideen hinter HTMX wichtiger sind als HTMX selbst

Experiment

• Nur die Dokumentation zu lesen reichte nicht aus, daher wurde die tatsächliche Nutzung getestet; Ziel für den HTMX-Einsatz war das Server-Refactoring einer selbst gehosteten Podcast-Web-App
• Die vorherige Implementierung nutzte SvelteKit; SvelteKit ist zwar ein bevorzugtes Tool, kann für kleine Websites aber ein schwergewichtiges Framework sein
• Ersetzt wurde es durch das selbst entwickelte DinoSsr, das im selben Projekt auch für statische Site-Builds und einen Bookmark-Blog verwendet wird
• DinoSsr ist hauptsächlich serverseitig ausgerichtet und kann Komponenten als Frontend-„Islands“ bereitstellen, bietet aber keine vollständige Interaktion auf Seitenebene
• Die Audio-Player-Komponente musste auch während Seitenwechseln erhalten bleiben; wenn ein Seitenwechsel die ganze Seite neu lädt, endet das Wiedergabeerlebnis sehr schnell
• SvelteKit übernahm UI-Updates und Frontend-Routing, doch im neuen Build verwendet nur noch die Audio-Player-Komponente Frontend-JavaScript, und DinoSsr versucht bewusst kein clientseitiges Routing
• Einige Seiten unterscheiden sich nur im ``-Abschnitt; wenn Links mit HTMX schrittweise verbessert und nur dieser Bereich aktualisiert wird, kann die Audio-Komponente erhalten bleiben, ohne die ganze Seite neu zu laden
• Der HTMX-Einsatz funktionierte gut, wurde aber bald wieder entfernt und durch eine selbst gebaute Mini-Version auf Basis derselben Ideen ersetzt

Einige Gedanken zu HTMX

• In diesem Experiment war HTMX ein Ersatz für Frontend-Svelte, aber kein direkt einsteckbarer Ersatz wie React, sondern eher ein grundlegender Wechsel der Denkweise
• HTMX wird als JavaScript-Bibliothek zur schrittweisen Verbesserung des Frontends ausgeliefert, doch der Großteil der Implementierung findet im Backend statt; Server-Templates und Konfiguration müssen direkt vorbereitet werden
• HTTP-Anfragen, die HTML liefern, fungieren praktisch als HTMX-API, und Details wie das Setzen von HTTP-Headern für korrektes Caching sind wichtig
• Dass statt standardisierter data-*-Attribute und dataset nicht standardisierte Attribute mit hx-*-Präfix verwendet werden, ist ein kleiner Kritikpunkt
• In der HTMX-Dokumentation gibt es viele ``-Beispiele; das folgende Beispiel sendet, wenn ein Nutzer auf ein div klickt, eine PUT-Anfrage an /messages und lädt die Antwort in dieses div

    Put To Messages

• Beispiele, bei denen Nutzer auf ein ``-Element klicken sollen, gelten als fragwürdig
• Einige fortgeschrittene HTMX-Beispiele mit Inline-JavaScript werden recht unübersichtlich und zeigen die Grenzen deklarativer Attribut-Templates
• Unabhängig von solcher Kritik bietet HTMX einen begrenzten, aber nützlichen Funktionsumfang und ist ein Werkzeug, mit dem sich viele gängige Webdesign-Muster verbessern lassen

Selbst bauen

• HTMX wurde direkt nach seiner erfolgreichen Integration wieder entfernt und durch eine selbst entwickelte Mini-Implementierung mit denselben Ideen ersetzt
• Um cachebare Fetch-Anfragen zu ermöglichen, wurden die HTTP-Header last-modified, if-modified-since und 304-Antworten verwendet
• Für die grundlegende History-Integration wurden pushState und popstate genutzt
• Es wurde Code hinzugefügt, um ``-Elemente zu extrahieren und zu ersetzen; außerdem wurde, inspiriert von der HTMX-Preload-Extension, Pointer-Event-basiertes Preloading eingebaut
• Pointer-Event-basiertes Preloading startet eine Fetch-Anfrage schon vor dem click-Event und bringt dadurch einen kleinen Performance-Gewinn
• Der experimentelle Quellcode ist sehr einfach, zeigt aber, wie wenig JavaScript der Browser tatsächlich braucht
• Ob mit HTMX oder nach dem Motto „we have HTMX at home“: Das Ergebnis war eine deutlich kleinere und einfachere Codebasis

Frontend-JavaScript

• Templates und Komponenten sind außer bei sehr kleinen Websites praktisch unverzichtbar für Code-Organisation und Wiederverwendung und lassen sich serverseitig in PHP, Ruby, Go, JavaScript und anderen Sprachen umsetzen
• Diese Struktur muss nicht im Browser dupliziert oder ausschließlich dort implementiert werden, doch mit der Popularität von React und ähnlichen Tools haben viele Entwickler aufgehört, diese Frage zu stellen
• Die Erschöpfung durch Frontend-JavaScript ist real und hängt mit der Erfahrung zusammen, alte Server-Templates zu bevorzugen und zugleich JS-UIs übermäßig kompliziert entworfen zu haben
• Selbst wenn HTMX selbst nicht außergewöhnlich großartig sein sollte, ist seine Philosophie ein so wertvoller Ansatz, dass sie moderne JavaScript-Entwickler fast beschämen könnte

[GN⁺]

Lobste.rs-Meinungen

• Kleine Spitzfindigkeit, aber ich mag es nicht besonders, hx-*-präfixierte HTML-Attribute dort zu verwenden, wo man data-* nutzen sollte Htmx unterstützt schon seit Langem das data--Präfix Wenn man verhindern will, dass Benutzer auf ``-Elemente klicken müssen, verwendet man hx-boost von htmx am besten mit Anchor- und Formular-Tags. Diese Tags werden damit auf die richtige Weise automatisch verbessert, sodass klickbare divs vermieden werden können Das ist ein Projekt, das zeigt, wie wenig JavaScript der Browser tatsächlich braucht, und künftig wird der Wartungsaufwand wohl minimal sein, ebenso der Bedarf an Security-Patches. Glückwunsch

• Rendert HTMX nicht alles und quält damit den Server? Das fühlt sich ähnlich an wie die CGI-Probleme, die wir früher hatten

  • Mit ziemlicher Sicherheit nicht. Das CGI-Problem waren vor allem die Kosten dafür, viele kurzlebige Prozesse zu starten, und das wurde mit Dingen wie FastCGI gelöst HTML zu erzeugen ist keine besonders teure Operation, und es ist schwer zu sagen, dass das teurer wäre als in alternativen Ansätzen eine ähnliche Menge JSON zu erzeugen
  • Ich weiß nicht, was mit „wir“ gemeint ist. Mein Blog basiert auf CGI, der Server rendert HTML, und es gibt überhaupt kein JavaScript Seit 1999 gab es damit keinerlei Probleme, und wie immer sollte man mit Profiling prüfen, wo der echte Flaschenhals liegt
  • Üblicherweise nennt man das Server-Side Rendering, aber tatsächlich ist es eher das Erzeugen von rohem HTML auf dem Server. Das eigentliche Rendering und die DOM-Erzeugung übernimmt weiterhin der Browser, und das war schon immer so Selbst wenn man PHP noch in die CGI-Kategorie steckt, würde man damit etwa anderthalb Jahrzehnte Webentwicklung überspringen, in denen genau diese Art der Entwicklung üblich war Es stimmt, dass der Server mehr Arbeit macht, aber ich denke, der Hauptgrund dafür, dass man so viel Verarbeitung auf den Client verlagert hat, war eher ein kalkuliertes Risiko zur Kostensenkung. Viele Endnutzer merken nicht, dass der Browser mehr Arbeit übernehmen muss, aber auf älteren oder leistungsschwachen Geräten ist die Erfahrung auch heute noch schlechter, besonders am Anfang HTMX ist allerdings nicht dasselbe wie vollständiges Server-Side Rendering. Statt dass eine API Daten als JSON schickt und der Client daraus HTML rendert, schickt der Server dieselben Daten als HTML-Fragmente. Wenn der Server trotzdem unter Last gerät, liegt das wahrscheinlich eher an anderen Faktoren als daran, dass es grundsätzlich ressourcenintensiver wäre als eine REST-API
  • Ohne Benchmarks ist das schwer sicher zu sagen, aber ich vermute, es ist ähnlich. In beiden Fällen gibt man am Ende einen Haufen Zeichen aus; der Unterschied ist, ob Text-Rendering teurer ist oder das Erzeugen von JSON Meiner Erfahrung nach serialisiert man bei JSON eher mehr, aber ich weiß nicht genau, wie man das sauber vergleichen sollte
  • Bei Server-Side-Anwendungen ist die eigentliche HTML-Rendering-Phase fast nie der Flaschenhals; der Engpass liegt meist davor

• Aus ähnlichen Gründen nutze ich alpine-ajax, das htmx sehr ähnlich ist

  • alpine-ajax gefällt mir auch wirklich gut. Wenn ich noch einmal neu mit dem Ansatz „in SSR die Vorteile einer SPA bekommen“ starten würde, wäre ich wahrscheinlich dort gelandet Ich nutze für clientseitige reaktive Funktionen ohnehin alpine. Allerdings steckt in meinem Repository inzwischen schon viel htmx, und ich habe auch nichts gegen htmx einzuwenden
  • Ich verwende datastar, und es war ziemlich angenehm, damit zu arbeiten