HTMX ist am stärksten, wenn die App überwiegend servergesteuert ist_

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

• HTMX-Dokumentation
• Buch über Hypermedia-Systeme