htmx gegen den Standard-SPA: Wenn Hypermedia ein JavaScript-Framework übertrifft.
Wie htmx-Attribute die Client-Seite-Rendering ersetzen, was die Bundle-Größen tatsächlich bedeuten, sowie eine ausgewogene Übersicht darüber, wo Hypermedia-Apps vorteilhaft sind und wo React weiterhin überlegen ist.
Viele Teams greifen bei jedem neuen Projekt auf React zurück, einschließlich Admin-Panels und CRUD-Tools, die hauptsächlich aus Formularen und Tabellen bestehen. htmx argumentiert, dass ein großer Teil dieser Anwendungen niemals ein Client-Side-Framework benötigt hat: Der Server kann HTML senden, und durch einige Attribute kann jedes Element Teile davon abrufen und austauschen. Diese Anleitung erklärt, wie htmx funktioniert, vergleicht seinen Ressourcenverbrauch mit dem von React und zeigt sowohl die echten Vorteile als auch die Einschränkungen auf, die Befürworter oft übergehen – damit Sie bewusst statt aus Gewohnheit eine Architektur wählen können.
Die Anleitung setzt voraus, dass Sie bereits Webanwendungen entwickelt haben und den größten Teil Ihrer Zeit mit React oder einem ähnlichen Framework verbracht haben.
Wie das SPA zur Standardlösung für alles wurde
Gegen 2013 wechselte die Branche ihr Kernmodell. Anstelle dass Server HTML-Seiten zurücklieferten, begannen sie, JSON zu liefern, und JavaScript im Browser wandelte dieses JSON in die Benutzeroberfläche um.
Für einige Produkte stellte die Single-Page-Anwendung einen echten Fortschritt dar. Gmail, Figma und Google Maps speichern viel Daten im Browser, weshalb die Interaktionen sofortig erscheinen müssen.
Das Problem ist, dass dieses Modell auf alles übertragen wurde. Ein internes Dashboard, das Zeilen auflistet und deren Bearbeitung ermöglicht, verfügt schließlich über dieselbe Architektur wie ein Designwerkzeug. Eine Marketing-Website mit einem Kontaktformular erhielt einen Bundler, einen Router, eine State-Bibliothek sowie einen Hydratierungsprozess.
Diese Standardlösung hat konkrete Kosten:
- Zwei Codebasen, oft in zwei verschiedenen Sprachen
- Das Datenmodell wird auf beiden Seiten definiert
- Eine Build-Toolkette, die gewartet und aktualisiert werden muss
Die zentrale Behauptung von htmx ist, dass viele Anwendungen diese Kosten tragen, ohne etwas Nützliches dafür zu erhalten.
Was htmx ist
htmx ist eine kleine JavaScript-Bibliothek, die HTML mit Attributen erweitert. Mit diesen kann jedes Element eine HTTP-Anfrage senden und die Antwort an einer bestimmten Stelle auf der Seite platzieren. Das ist im Grunde genommen die gesamte Bibliothek.
Ein Live-Suchfeld veranschaulicht diese Idee. Das Eingabefeld gibt an, welche URL aufgerufen werden soll, welches Ereignis den Aufruf auslöst und wohin das Ergebnis gelangen soll:
<input type="text"
name="q"
hx-get="/search"
hx-trigger="keyup changed delay:300ms"
hx-target="#results">
<div id="results"></div>
Lesen Sie die Attribute als Satz: Wenn eine Tastenkombination losgelassen wird und der Wert tatsächlich geändert wurde, warten Sie 300 ms, senden Sie eine GET-Anfrage an /search und fügen Sie den zurückgegebenen Inhalt in #results ein. Der Modifikator delay:300ms dämpft die Eingaben, sodass schnelles Tippen keine Anfrage pro Tastendruck sendet.
Der Server gibt kein JSON zurück. Er gibt ein fertiges HTML-Fragment zurück:
<ul>
<li>First result</li>
<li>Second result</li>
</ul>
htmx fügt dieses Fragment in das Zielelement ein. Es findet keine JSON-Parse statt, es gibt kein Client-Seiten-Template und keinen Client-Zustand, der sich vom Server unterscheiden könnte.
Die Attribute, die Sie am häufigsten verwenden werden
hx-get,hx-post,hx-put,hx-deletewählen die HTTP-Methode und die URL aus.
hx-trigger legt das Ereignis fest, das die Anfrage auslöst, wie z. B. click, keyup, load, every 2s oder revealed (wenn das Element in Sicht kommt).hx-target wählt das Element aus, das die Antwort erhält.hx-swap steuert, wie die Antwort eingefügt wird: innerHTML, outerHTML, beforeend oder delete.hx-indicator weist auf ein Element hin, das während der Übertragung der Anfrage angezeigt wird.hx-confirm bittet den Benutzer, vor dem Senden zu bestätigen.Diese Elemente passen gut zusammen. Der nächste Codeausschnitt löscht eine Tabellenzeile: Die Schaltfläche sendet einen DELETE-Anfragen, richtet sich auf die nächstgelegene umschließende tr-Element, ersetzt die gesamte Zeile durch die (in der Regel leere) Antwort und bittet zunächst um Bestätigung. Der Modifikator swap:1s verzögert den Austausch um eine Sekunde, wodurch Zeit für eine CSS-Übergangsanimation zur schrittweisen Ausblendung der Zeile entsteht und die Aktion responsiv wirkt:
<tr>
<td>Widget</td>
<td>
<button hx-delete="/items/42"
hx-target="closest tr"
hx-swap="outerHTML swap:1s"
hx-confirm="Delete this item?">
Delete
</button>
</td>
</tr>
Beachten Sie, was fehlt: Es gibt keine separate JavaScript-Datei, keinen Build-Schritt und keinen Client-Seiten-Zustand. Der Server bleibt für das Löschen des Elements sowie die Entscheidung darüber verantwortlich, was aus der Zeile werden soll.
Zwei Architekturen nebeneinander
Der Unterschied wird als Ablauf klarer dargestellt als durch einen Vergleich der Werkzeuge.
- SPA-Modell: Der Server sendet JSON, der Client-Code rendernt es und verwaltet den Zustand. Der Benutzer handelt, der Client aktualisiert seinen Zustand, rendernt erneut und sendet JSON zurück.
- Hypermedia-Modell: Der Server sendet HTML, der Browser zeigt es an. Der Benutzer handelt, der Server antwortet mit neuem HTML und der Browser ersetzt es.
Im Hypermedia-Modell gibt es genau eine einzige Quelle der Wahrheit: den Server. Dadurch entfallen ganze Gruppen von Fehlern, bei denen der Client etwas anderes annimmt als die Datenbank angibt – wie veraltete Caches oder optimistische Updates, die nie abgeglichen wurden.
Carson Gross, der htmx entwickelt hat, präsentiert dies als Rückkehr zu dem, wofür REST ursprünglich gedacht war. Roy Fieldings REST beinhaltet die HATEOAS-Vorgabe (Hypermedia As The Engine Of Application State): Der Server sendet Darstellungen, die die nächsten verfügbaren Aktionen enthalten. Eine typische JSON-API tut dies nicht; der Client muss im Voraus wissen, welche Endpunkte vorhanden sind. HTML erledigt dies nativ, denn ein Link stellt einen Zustandswechsel dar und ein Formular eine Aktion. Ob Ihnen diese Sichtweise als aufschlussreich oder akademisch erscheint, ist ein guter Indikator dafür, wie Sie htmx insgesamt wahrnehmen werden.
Messung der Dateigröße – und was sie nicht verrät
Anggebene Größen variieren, daher hilft es, sie zu messen. Zum Zeitpunkt der Erstellung wog die minifizierte htmx-Version wie folgt:
htmx.min.js: 51,238 bytes raw
16,576 bytes gzipped (16.2 KB)
Die Produktversionen von React 19.2.8, das React-Paket zusammen mit dem DOM-Client, wogen wie folgt:
react.production.js: 4,446 bytes gzipped
react-dom-client.production.js: 94,757 bytes gzipped
combined: 98,420 bytes gzipped (96 KB)
Das ist ein Unterschied von etwa sechsmal – und bezieht sich dabei nur auf den React-Runtime. Eine echte React-App enthält außerdem einen Router, eine State-Bibliothek, eine Schicht zur Datenerfassung sowie eigene Komponenten, wodurch die bereitgestellten Bundle-Dateien in der Regel mehrere hundert Kilobyte umfassen. Im Gegensatz dazu repräsentiert die Zahl für htmx die gesamten Client-Seite-Abhängigkeiten. Genaue Zahlen ändern sich mit jeder Veröffentlichung, daher sollten Sie erneut messen, basierend auf den Versionen, die tatsächlich bereitgestellt werden.
Achten Sie jedoch auf die Schlussfolgerung: Die Größe des Bundles beeinflusst nur die erste Ladezeit, nicht die Geschwindigkeit der anschließenden Interaktionen. Bei einer guten Verbindung ist der Ladezeitunterschied gering, und bei wiederholten Besuchen stammen beide Dateien aus dem Cache. Ein überzeugenderes Leistungsargument ist, dass htmx keine Hydratierungsphase aufweist – also die Zeit, in der eine auf dem Server gerenderte React-Seite scheinbar bereit ist, aber Klicks ignoriert, bis ihre Event-Handler hinzugefügt werden.
Wo htmx tatsächlich hilft
- Eine Sprache und eine Codebasis. Ein Team, das mit Go, Python, Ruby oder C# arbeitet, kann die gesamte Anwendung entwickeln. Die Validierung findet an einem Ort statt und das Datenmodell wird nur einmal definiert.
- Kein Build-Pipeline. Ein einziger
script-Tag reicht aus. Es gibt keine Konfiguration eines Bundlers, keine frontend-node_modules-Strukturen und keinen Aufwand durch Updates von Frontend-Abhängigkeiten. - Lokalität des Verhaltens. Was ein Element tut, ist direkt auf dem Element selbst festgelegt. Anstatt einem Klick durch mehrere Dateien und einen Speicher folgen zu müssen, liest man einfach die Markup-Struktur. Das ist einer der stärksten Vorteile und bezieht sich auf Wartbarkeit statt auf Geschwindigkeit.
- Zustand an einem Ort. Es gibt keinen Client-Cache, den man für ungültig erklären müsste, keine veralteten Daten und keine optimistischen Updates, die rückgängig gemacht werden müssen.
Wo htmx nachlässt
Das sind die Punkte, die oft unerwähnt bleiben.
Reiche, kontinuierliche Interaktion
Drag-and-drop-Funktionen, Canvas-Editor, Tabellenkalkulationen sowie interaktive Diagramme mit Zoom- und Wischfunktionen erfordern eine kontinuierliche Interaktion statt einzelner Anfragen. Bei htmx bedeutet jede Interaktion eine Hin- und Rückreise zum Server. Bei einem Texteditor ist das kein Kompromiss – es schließt htmx somit aus.
Verzögerungen in schlechten Netzwerken
Befürworter weisen darauf hin, dass Edge-Hosting die Hin- und Rückreisezeiten erheblich verkürzt hat, was zutrifft. Dennoch kann ein Nutzer mit einer schwachen mobilen Verbindung auf dem Land mehrere hundert Millisekunden warten, während React solche Aufgaben lokal in wenigen Millisekunden erledigen würde. htmx-Apps funktionieren auf guten Netzwerken hervorragend, sind aber auf schlechten Netzwerken deutlich langsamer – das ist das Gegenteil von der üblichen Darstellung dieses Arguments.
Keine Vorteile für Mobilgeräte oder den Offline-Modus
htmx ist ausschließlich für das Web gedacht. React Native ermöglicht es einem Team, Konzepte sowie einen erheblichen Teil des Codes mit nativen Apps zu teilen; daher kann dies, falls native Mobile-Anwendungen im Plan stehen, alle anderen Faktoren überwiegen. Ein Offline-Betrieb ist ebenfalls nicht möglich, da jede Interaktion den Server erfordert.
Komplexe Client-Seiten-States
Mehrschrittige Assistenten mit voneinander abhängigen Feldern, Formulare mit Echtzeit-Validierung über verschiedene Felder oder Bildschirme, bei denen mehrere Komponenten auf eine Änderung reagieren müssen, gestalten sich schwierig. Teams fügen in der Regel Alpine.js oder hyperscript hinzu – an diesem Punkt bauen sie eigentlich ein Framework aus Einzelteilen zusammen, anstatt eines vorgefertigten zu verwenden.
Ein kleines Ökosystem und ein begrenzter Talentpool
React verfügt über eine ausgereifte Komponente für nahezu jedes Widget. Mit htmx kann man entweder einen eigenen Datumsauswahler entwickeln oder einen eigenständigen JavaScript-Dateumsauswahler einbinden und die Grenzen selbst steuern. Auch die Vertrautheit spielt eine Rolle: Zum Zeitpunkt der Erstellung zeigten Umfragen, dass React von rund 40 Prozent der Entwickler genutzt wird, während htmx nur bei etwa 7 Prozent Verbreitung hat – bei den npm-Downloads liegt das Verhältnis bei etwa 560 zu 1. Das beeinflusst, wie schnell neue Mitarbeiter produktiv werden und wie leicht man Antworten findet, wenn man auf ein Problem stößt.
Aufmerksames Lesen der Adoptionszahlen
Das tatsächliche Bild ist differenzierter, als es jede der beiden Seiten nahelegt.
- Die Nutzung von React nimmt nicht ab. Sie bleibt in absoluten Zahlen mit einem sehr großen Vorsprung dominierend.
Zusammenfassend lässt sich sagen: React wird nicht ersetzt, doch seine Stellung als unangefochtener Standard schwächt sich ab. Bedenken Sie, dass ein Großteil der online verfügbaren Inhalte zu htmx im Vergleich zu React für Suchverkehr geschrieben wurde, und Zahlen wie der Prozentsatz der Codeverkürzung oder verschiedene Geschwindigkeitswerte werden oft ohne Quellenangabe wiederholt. Betrachten Sie sie als Richtwert und prüfen Sie die aktuellen Quellen, bevor Sie sie zitieren.
Die Wahl zwischen ihnen
Wählen Sie htmx, wenn:
- Die Anwendung im Grunde aus Formularen und Listen besteht: Admin-Panels, interne Tools, CRUD-Anwendungen, Inhaltsseiten, Dashboards, die Daten anzeigen statt sie zu verarbeiten.
- Die Stärke Ihres Teams im Backend liegt.
- Sie eine einzige Codebasis möchten, die auch in einigen Jahren noch von jedem im Team gewartet werden kann.
Wählen Sie React, wenn:
- Der Browser tatsächlich einen erheblichen Zustand speichert, wie bei Editoren, Design-Tools, Echtzeit-Kollaboration oder umfangreicher Datenverarbeitung.
- Ihnen native Mobile-Apps oder Offline-Funktionalität benötigt werden.
- Sie auf ein ausgereiftes Komponenten-Ökosystem angewiesen sind.
Es gibt auch eine dritte Option, die oft übersehen wird: Beides verwenden. htmx kann die CRUD-Bildschirme bereitstellen, während React die zwei oder drei Ansichten antreibt, die es wirklich benötigen. Nichts zwingt dazu, in einem gesamten Produkt eine einzige Architektur zu verwenden – und die Kombination von htmx mit einem React-Abschnitt ist einfacher als die Kombination zweier SPA-Frameworks. Falls Sie bereits mit htmx arbeiten, behandelt der Upgrade-Guide für htmx 4 die Änderungen in der nächsten Major-Version.
React Server Components übernehmen teilweise die Idee des Hypermedias, indem sie das Rendering auf den Server verlagern. Allerdings benötigen sie weiterhin die volle React-Laufzeitumgebung sowie einen Node-fähigen Server, weshalb sie keine leichte Alternative darstellen; es handelt sich dabei um React, das einige der gleichen Vorteile erhält, ohne an Gewicht zu verlieren.
Hauptergebnisse
- htmx ermöglicht es jedem Element, eine Anfrage zu senden und durch serverseitig generiertes HTML ersetzt zu werden, wodurch der Server als einzige Quelle der Wahrheit bleibt und eine Synchronisierung des Client-Zustands entfällt.
- Seine Laufzeit beträgt ungefähr ein Sechstel der von React, noch bevor Code für eine React-Anwendung hinzugefügt wird, doch der praktische Vorteil liegt eher im Vermeiden des Hydratierungsprozesses als in einer verkürzten Ladezeit.
- Er eignet sich hervorragend für CRUD-Anwendungen, interne Tools und Inhaltsseiten, hat jedoch Schwierigkeiten bei kontinuierlicher Interaktion, schlechten Netzverbindungen, mobiler Nutzung, Offline-Verwendung sowie komplexem Client-Zustand.
- Die Kombination beider Ansätze stellt eine legitime Architektur dar und kein Kompromiss.
Die wichtigere Frage hinter dieser Debatte ist, wie eine für Gmail konzipierte Architektur zur Standardlösung für ein Formular mit sechs Feldern wurde. Niemand hatte im Grunde Unrecht; ein Werkzeug wurde zum Standard, und Standards werden nicht weiter geprüft. Was auch immer Sie wählen – einschließlich React – sollten Sie eine bewusste Entscheidung treffen, anstatt etwas einfach zu übernehmen.
Verwandte Artikel
- React’s Scheduler und der Event Loop: Wer entscheidet wirklich, wann Aufgaben ausgeführt werden – Erfahren Sie, wie Reacts kooperativer Scheduler innerhalb des JavaScript-Event-Loops arbeitet, warum Übergänge unterbrochen werden können und warum kein Scheduler einen blockierten Thread retten kann.