HTMX ist attraktiv, weil es Teams ermöglicht, interaktive Webanwendungen zu erstellen, ohne sich sofort auf eine umfangreiche Client-seitige Zustandsarchitektur festzulegen.
Das ist besonders wichtig für Anwendungen, bei denen die Arbeit überwiegend aus Folgendem besteht:
- Formularen
- Tabellen
- Filtern
- partiellen Seitenaktualisierungen
In diesen Systemen ist das Senden von HTML vom Server oft eine einfachere Lösung als der Aufbau einer parallelen JSON-API plus einer Client-seitigen Renderingschicht für alles.
Der Wertvorschlag
Eine einfache Interaktion kann einfach bleiben:
<form hx-post="/settings/profile" hx-target="#profile-panel" hx-swap="outerHTML">
<input name="displayName" />
<button type="submit">Speichern</button>
</form>
Der Backend gibt aktualisiertes HTML zurück. HTMX tauscht es an der Stelle aus. Es gibt weniger Client-Zustand zu synchronisieren, weil der Server die Quelle der Wahrheit sowohl für Daten als auch für Markup bleibt.
Wo es am besten passt
HTMX ist am stärksten, wenn:
- der Backend bereits Templates rendert
- die App überwiegend Interaktionen mit Anfrage/Antwort hat
- die Komplexität auf der Client-Seite derzeit die Produktbedürfnisse übersteigt
Es ist schwächer, wenn:
- die Benutzeroberfläche stark client-gesteuert ist
- Offline- oder lokal zuerst Verhaltensweisen wichtig sind
- Echtzeitanalysen dicht und zustandsbehaftet sind
Deshalb ist HTMX nicht „besser als React.“ Es ist besser, als eine Client-Anwendung übermäßig zu erstellen, wenn eine servergesteuerte Anwendung die Aufgabe sauberer erledigen kann.
Abwägungen
HTMX bietet weniger Komplexität auf der Client-Seite, aber auch weniger der Client-Laufzeitkontrolle, in der React-artige Apps hervorragend sind. Die richtige Entscheidung hängt von der Form des Produkts ab, nicht davon, welche Gruppe online lauter ist.
Weiterführende Informationen