HTMX – bitte probiert es wenigstens einmal aus

(pleasejusttryhtmx.com)

21 Punkte von GN⁺ 2025-12-19 | 8 Kommentare | Auf WhatsApp teilen

In der modernen Webentwicklung treibt die falsche Gegenüberstellung von HTML und großen JavaScript-Frameworks Entwickler in unnötige Komplexität
HTMX verarbeitet AJAX-Anfragen, partielle Updates und Animationsübergänge allein mit HTML-Attributen und bietet damit einen Ansatz, bei dem vom Server zurückgegebenes HTML direkt in die Oberfläche übernommen wird
Es lässt sich schrittweise einführen, ohne die bestehende Codebasis grundlegend zu verändern, reduziert die Frontend-Komplexität und erhöht Produktivität und Wartbarkeit
Gegenüber React-basierten SPAs wurden in echter Produktion deutliche Verbesserungen bei Codeumfang, Abhängigkeiten, Build-Zeit und Ladegeschwindigkeit bestätigt
Statt übermäßig komplexe Frameworks zu wählen, ist ein einfacher hypermedienbasierter Ansatz langfristig vorteilhafter für Produktivität und Wartbarkeit

Das Problem: die falsche Wahl in der Webentwicklung

In Diskussionen zur Webentwicklung werden immer wieder nur extreme Alternativen präsentiert: entweder nur HTML oder ein großes Framework wie React
Reines HTML ist bei Grundfunktionen wie Links, Formularen und dialog stark, hat aber Grenzen bei partiellen Updates und unmittelbarer Reaktivität
Wer sich für React, Vue oder Angular entscheidet, bekommt Hunderte von Abhängigkeiten, langsame Builds und endlose Debatten über komplexes State Management dazu
Selbst auf einfache CRUD-, Dashboard- oder formularzentrierte Apps wird in der Praxis oft ein überdimensionierter Tool-Stack angewendet

Das Kernkonzept von HTMX

HTMX ist ein Werkzeug, das durch spezielle Attribute auf HTML-Elementen asynchrone Kommunikation mit dem Server ermöglicht
- Mit Attributen wie hx-get und hx-post können etwa Anfragen gesendet und Antworten in einen bestimmten DOM-Bereich eingefügt werden
Es erweitert HTML so, dass jedes HTML-Element ein Auslöser für HTTP-Anfragen sein kann
Der Server gibt kein JSON zurück, sondern direkt HTML-Fragmente, die an der angegebenen Stelle automatisch ersetzt oder eingefügt werden
Das Verhalten wird allein über HTML-Attribute deklariert, ohne eigenes JavaScript zu schreiben
Die Bibliothek ist mit rund 14 KB (gzip) sehr leichtgewichtig
Ohne separate Build-Tools oder Framework-Konfiguration lässt sie sich direkt in bestehende HTML-Dokumente einbinden
Die Struktur passt gut zu einem traditionellen, serverseitig gerenderten Webentwicklungsansatz

Wichtige Funktionen

AJAX-Anfragen verarbeiten: GET- und POST-Anfragen allein über HTML-Attribute ausführen
DOM-Updates: Vom Server zurückgegebenes HTML automatisch in das gewünschte Element übernehmen
Event-Verarbeitung: Serveraufrufe mit Benutzerereignissen wie Klicks oder Eingaben verknüpfen
History-Verwaltung: Mit Zurück- und Vorwärts-Navigation des Browsers integrieren

Praxisbeispiele und Kennzahlen

Contexte hat ein React-basiertes SaaS auf Django + HTMX umgestellt
- Gesamtzahl der Codezeilen um 67 % reduziert (21.500 → 7.200)
- JavaScript-Abhängigkeiten um 96 % reduziert (255 → 9)
- Build-Zeit um 88 % verkürzt (40 Sekunden → 5 Sekunden)
- Seitenladegeschwindigkeit um 50–60 % verbessert
Zwei Drittel der Codebasis wurden gelöscht, und die App wurde dabei besser
Ohne Trennung zwischen Frontend und Backend können alle Entwickler Full-Stack arbeiten

Häufige Einwände kurz eingeordnet

"Braucht man nicht komplexes clientseitiges State Management?"
- In der Praxis geht es meist nur um Formulare, Listen und bei Klick erscheinende Elemente, und dafür reicht HTMX völlig aus
- Echtzeit-Kollaboration wie in Google Docs ist eine Ausnahme, aber die meisten überschätzen die Komplexität von CRUD-Apps
"Welche Vorteile bringt das React-Ökosystem nicht trotzdem?"
- Ein riesiges Ökosystem bedeutet oft auch mehrere GB an node_modules, endlose Auswahlmöglichkeiten und Debatten über State Management
- Das Ökosystem von HTMX endet im Wesentlichen bei einer gewählten serverseitigen Sprache
"Ist eine SPA gefühlt nicht trotzdem schneller?"
- Zu Beginn müssen erst große JavaScript-Bundles heruntergeladen, geparst, ausgeführt und hydratisiert werden
- HTMX ist schon beim initialen Laden schnell und tauscht danach nur noch die tatsächlich geänderten Teile aus, wodurch die Reaktionsgeschwindigkeit erhalten bleibt
Anzeige
"Was ist, wenn man bestimmte React-Funktionen wirklich braucht?"
- In manchen Fällen kann React geeignet sein
- In der Praxis wird jedoch oft gewohnheitsmäßig ein Werkzeug gewählt, das nur für einen kleinen Teil des Gesamtproblems nötig wäre
Warum sollte man HTMX wählen?
- Teams scheitern nicht wegen des falschen Frameworks, sondern wegen der Wahl eines übermäßig komplexen Frameworks
- HTMX setzt auf Einfachheit, und langfristig bringt Einfachheit Vorteile bei Wartbarkeit und Produktivität

Wann HTMX nicht passt

Echtzeit-Kollaborationstools (Google Docs, Figma)
Anwendungen mit umfangreichen clientseitigen Berechnungen (Video-Editoren, CAD-Tools)
Offline-First-Architekturen (wobei sich auch mehrere Ansätze kombinieren lassen)
Fälle mit wirklich komplexem UI-State

Aber baut ihr wirklich so etwas?
- Baut ihr nicht eher noch ein weiteres Dashboard, Admin-Panel, E-Commerce-Portal, Blog oder eine SaaS-App, die im Kern aus Formularen, Tabellen und Listen besteht?
- Dafür ist HTMX wirklich erstaunlich gut — so gut, dass man sich fragt: "Warum haben wir das so kompliziert gemacht?" oder "Mein Gott, wir haben all die Zeit verschwendet"
Anzeige

Also: probiert es einmal aus

Ihr habt React benutzt, Vue ausprobiert und Angular vermutlich getestet und bereut, oder?
- Und wahrscheinlich habt ihr auch das Meta-Framework angerührt, das diese Woche auf Hacker News gerade im Trend ist
Probiert HTMX einfach einmal aus
- Investiert ungefähr einen Tag am Wochenende
- Nehmt euch ein Side-Project vor oder
- sucht euch ein internes Tool aus, um das sich niemand besonders schert, oder
- holt etwas hervor, das ihr ohnehin irgendwann einmal neu bauen wolltet
Fügt einfach ein <script>-Tag hinzu und schreibt ein hx-get-Attribut, dann schaut euch direkt an, wie es funktioniert
Im schlimmsten Fall verliert ihr einen Tag am Wochenende, der Schaden hält sich also in Grenzen
- Aber vermutlich wird es euch nicht missfallen
- Eher werdet ihr euch fragen, warum Webentwicklung überhaupt so kompliziert geworden ist

8 Kommentare

ryj0902 2025-12-22

Ich erinnere mich, dass ich auf der PyCon einmal einen entsprechenden Vortrag gehört habe und der Vortragende auch meinte, er habe es bisher noch nicht in der Praxis einsetzen können.

aer0700 2025-12-21

Rust, probieren Sie es bitte nur einmal aus?

bbulbum 2025-12-20

Ich habe Alpine.js schon einmal ausprobiert, aber State-Management brauchte ich größtenteils trotzdem ...
Wenn es nicht von Anfang an so entworfen ist, dass das Backend das State-Management übernimmt, erinnere ich mich daran, wie mühsam es war, Dinge wie schrittweise Zustände oder bedingte Zustände zu lösen.

roxie 2025-12-20

Ich stimme allem zu, aber irgendwie greife ich trotzdem nicht zu htmx :(

GN⁺ 2025-12-19

Hacker-News-Kommentare

Ich bin der Gründer von htmx. Ich bin dankbar für die Aufmerksamkeit durch solche übertriebenen Artikel, aber ich mag diesen Hype nicht besonders.
Es gibt viele Wege, Web-Apps zu bauen, und jeder hat Vor- und Nachteile. Die Stärken und Schwächen von htmx habe ich in diesem Artikel zusammengefasst.
Ich empfehle auch ausdrücklich, Unpoly auszuprobieren, eine weitere großartige hypermedia-orientierte Bibliothek.
(Nachtrag) Nachdem ich den Artikel noch einmal gelesen habe, fand ich ihn besser als gedacht. Trotzdem würde ich mir wünschen, dass htmx mit etwas ruhigerem Ton behandelt wird.
- Wenn man damit vertraut ist, wie man Anfang der 1990er Web-Apps gebaut hat, kann man mit HTMX mit wenig Aufwand interaktive Funktionen leicht hinzufügen.
  Feldaktualisierungen per Dropdown, Modals, Autocomplete-Suchfelder — alles ist einfach.
  Die eigentliche Komplexität von RIA-Frontends liegt allerdings darin, wie das Frontend bei Datenänderungen aktualisiert wird.
  Dafür braucht man auf dem Backend etwas Abstimmung, und noch besser ist eine Struktur, die mehrere partielle Updates gemeinsam verarbeiten kann.
- Es gibt auch den Artikel HTMX Sucks. Eine interessante Perspektive.
- Unpoly sieht wirklich großartig aus. HTMX habe ich noch nicht benutzt, aber mir gefällt, dass es UX-Probleme in Frameworks wie Django oder Rails mit wenig Aufwand löst.
  Ich mache gerade ein Side-Project mit Rails + Stimulus, und Stimulus wirkt eher übertrieben. Ich frage mich, wann man Inertia oder Stimulus wählen sollte.
- Zur Info: Ich bin der CEO von htmx, und ich liebe solche übertriebenen Artikel wirklich.
- Die Dokumentation von Unpoly ist ebenfalls großartig, wirkt aber etwas komplex. Für einfachere Fälle nutze ich Alpine AJAX.
  Es ist ein Alpine.js-Plugin, das Links und Formularen grundlegende AJAX-Funktionen hinzufügt.
Ich bin diese Artikel leid, die mit einem „Hello World“-Beispiel behaupten, besser als React zu sein.
In einfachen Beispielen funktioniert alles gut. In der Realität hat man aber meistens ein Backend mit vielen Abhängigkeiten und eine komplexe UI.
- Die Sorge von Entwicklern bei ultraleichten Frameworks ist letztlich, dass sie an Grenzen der Skalierbarkeit stoßen.
  Die Basis-Demos sind schön, aber man muss auch zeigen, wie sich komplexere Funktionen später erweitern lassen.
  Man will wissen, wo man JS ergänzt, ob ein Build-Step nötig ist und wie stark man an das Paradigma von htmx gebunden ist.
- Es gibt auch Apps wie Fizzy, die 37signals mit Hotwire gebaut hat.
  Es ist weniger „besser als React“ als vielmehr ein anderer Ansatz.
- Unser Intranet läuft mit Python + HTMX. Bisher gab es nichts, was wir damit nicht konnten.
  Das Paradigma, Teile des DOM auszutauschen, ist sehr simpel und intuitiv.
- Umgekehrt gibt es auch zu komplexe Technologien, bei denen schon „Hello World“ schwierig ist.
  Beispiel: effect-ts ist leistungsfähig, aber selbst einfache Ausgabe ist kompliziert.
- Es gibt eine Echtzeit-Planning-Poker-App, die mit Go + Htmx gebaut wurde. Sie kommt auf etwa 500 Zeilen Code.
Unser Startup hat HTMX eingeführt, wechselt jetzt aber letztlich zu React.
Bei HTMX ist die Komplexität der Response-Verarbeitung hoch, und jeder Endpunkt muss mehrere HTML-Fragmente zurückgeben.
Es gibt zu wenig Dokumentation und Beispiele, und auch Best Practices für große Systeme fehlen.
React ist ausgereift und passt auch gut zu AI Coding. Für einfache Projekte eignet sich HTMX, darüber hinaus wird es schwierig.
- Ich habe mit HTMX ein sauberes Architektur-Pattern gefunden.
  Jeder Endpunkt erfüllt nur eine Aufgabe, und mit Optimistic UI reagiert die Oberfläche sofort.
  Fehlerbehandlung bleibt einfach, und hx-swap-oob verwende ich nur minimal.
  Bei der Technologiewahl geht es im Kern darum, Trade-offs zu minimieren.
- Dass sich Frontend und Backend auf alle Szenarien einigen müssen, ist selbstverständlich.
  Deshalb setze ich auf backendzentrierte Validierung, und das Frontend zeigt nur an.
- Das Buch Hypermedia Systems erklärt das Gesamtbild besser.
- Eine Nischenlösung zu wählen, die man nicht verstanden hat, und dann zu einer anderen komplexen Lösung zu wechseln, heißt nur, Trade-offs zu wiederholen.
- Eine Technologie zu wählen, weil sie „gut für AI Coding“ ist, ist schon etwas traurig.
Ich will kein SSR. Das Backend soll nur eine JSON API bereitstellen, und das Frontend konsumiert sie.
SSR ist überhypt, denke ich. Es wirkt wie eine Lockstrategie, um Cloud-Services zu verkaufen.
Das Beispiel Demo 3 Live Search hat ein starkes Scroll-Jank-Problem.
Die Ergebnisse werden direkt ins Dokument eingefügt, wodurch das Layout offenbar ständig neu berechnet wird.
React ist völlig in Ordnung. Selbst bei einfachen Projekten gibt es keinen zwingenden Grund, ein anderes Paradigma zu lernen.
- React rendert am Ende auch nur HTML, also muss man HTML/CSS lernen. Es gibt lediglich eine Abstraktion darüber.
- Das React-Ökosystem ist so groß, dass man ständig lernen und wieder vergessen muss.
  HTMX dagegen versteht man in 15 Minuten und kann es 10 Jahre lang nutzen.
- React oder Angular sind Strukturen, die ein weiteres MVC auf ein MVC stapeln. Unnötig komplex.
- Schwere Lösungen überall einzusetzen ist ineffizient.
  Historisch haben sich leichtgewichtigere Paradigmen am Markt durchgesetzt. React war selbst einmal so etwas.
- Der Grund ist einfach — Performance.
Ich bin nicht auf HTMX, sondern komplett auf Alpine.js hereingefallen.
Das Konzept, servergerendertes HTML zu enhancen, hat bei mir sofort Klick gemacht.
Dropdowns, show/hide und Ähnliches sind alle intuitiv, und man braucht keinen Build-Step.
- Auch für Alpine gibt es das Plugin Alpine AJAX, das ähnliche Funktionen wie HTMX bietet.
- Ich nutze auch Alpine.js, und dadurch macht Frontend wieder Spaß.
  Es ist intuitiv und lässt sich selbst in größeren Projekten gut pflegen.
- In kommerziellen Projekten kann Alpine aber zum Albtraum werden.
  Wenn man JS inline in HTML schreibt, wird die Wartung schwierig, und das State-Management bleibt implizit.
  Hotwire oder Stimulus wirken auf Organisationsebene deutlich besser.
- Ein deklarativer Ansatz ist die richtige Antwort.
Wenn man HTMX in großen Apps einsetzt, würde mich Serverlast und Kosten interessieren.
Da HTML auf dem Server gerendert wird, wirkt es, als wäre der Aufwand höher als bei JSON.
- Das muss aber nicht so sein. Template-Rendering ist sehr schnell.
  Es kann sogar effizienter sein als JSON-Serialisierung, und auch auf Client-Seite gibt es Deserialisierungskosten.
  Zusammen mit Tools wie Alpine.js kann HTMX auch komplexeren State leicht handhaben.
  Es passt nicht zu jeder Situation, aber in vielen Fällen funktioniert es sehr gut.
Framework-Evangelismus ist die schlechteste Kultur im Web-Ökosystem.
Wenn eine Lösung gut ist, wird sie sich am Ende durchsetzen. Man muss sich nicht wie ein Missionar verhalten.
Auch die npm-Angriffe sind übertrieben. htmx wird am Ende ebenfalls npm benutzen müssen.
- htmx ist eine einzelne Datei ohne Abhängigkeiten, daher braucht man npm nicht zwingend.
- Die Aussage „Gute Lösungen werden ganz von selbst übernommen“ stimmt nicht.
  Es gibt viele schlechte Lösungen in der Welt, die wegen Marketing und Bekanntheit übernommen wurden.
- Beliebtheit, Budget und Trägheit entscheiden über Technologieeinführung.
  Wer echte Handwerkskunst bewahren will, muss sich solchen Verzerrungen widersetzen.
HTMX wirkt, als würde es nur die Nachteile beider Welten kombinieren.
SSR ist kohärent, CSR ist getrennt strukturiert, aber HTMX mischt beides und erzeugt dadurch implizite Kopplung.
Wenn man dieselben Daten in einem anderen Format zeigen will, muss man sich fragen, ob das Backend dafür zwei Endpunkte bauen muss.
- Man muss sich von der Vorstellung lösen, dass Frontend-State zwingend nötig ist.
  Für die meisten Apps reicht Backend-State völlig aus, und abgesehen von besserer UX bringt Frontend-State oft wenig.
- Der Artikel Splitting Your APIs zeigt eher, warum das ein Vorteil ist.
- Wenn man Server-Templates wie Jinja nutzt, kann man mit einem Render-Durchlauf mehrere Darstellungsformen abdecken.
  Wenn der Server die ganze Seite zusammensetzt, sind die Daten darin ohnehin schon vorhanden.

iolothebard 2025-12-20

Letztes Jahr habe ich wohl so einen Vortrag gehalten. Es haben zwar nicht viele Leute zugehört^^
https://www.slideshare.net/slideshow/htmx-2024/274315966

Als PoC habe ich auch so etwas gebaut.
https://github.com/iolo/hx

Aber niemand benutzt htmx, haha

shakespeares 2025-12-21

Schade, dass sich die inzwischen vertraute Situation nach dem Aufbau eines entsprechend großen Ökosystems verfestigt hat und es so wirkt, als gäbe es keine Bewegung hin zu weiterer Innovation mehr.