Ich gebe es ehrlich zu: Als ich das erste Mal von HTMX gehört habe, war ich skeptisch. Dynamische Webanwendungen ohne JavaScript-Frameworks? Das klang für mich wie ein schlechter Witz. Und nächstes Jahr programmieren wir dann alle wieder mit jQuery, oder was?

Aber dann ist etwas Seltsames passiert. Plötzlich tauchte HTMX überall auf. Die GitHub-Sterne kletterten in die Höhe. Entwickler, die ich respektiere, schwärmten davon. Unternehmen wechselten still und heimlich ihren Tech-Stack. Also habe ich getan, was jeder neugierige Entwickler tun würde: Ich habe es ausprobiert.

Und manchmal liegt das Internet eben doch richtig.

Das Problem, über das niemand spricht

Lass uns mal ehrlich darüber reden, wie das Bauen einer "modernen" Webanwendung im Jahr 2025 aussieht. Du willst eine simple Todo-Liste programmieren? Kein Problem. Hier ist, was du wahrscheinlich tun wirst:

Node.js installieren. Ein React- oder Vue-Projekt mit Vite aufsetzen. Build-Tools konfigurieren. State-Management hinzufügen, weil deine App das "später definitiv brauchen wird". Eine Routing-Library einbinden. Einen API-Client installieren. TypeScript konfigurieren. Ein Bundler-Optimierungs-Plugin hinzufügen. Testing-Libraries installieren.

Und jetzt willst du eine einzelne Checkbox hinzufügen? Dafür musst du State aktualisieren, Effects verwalten, Re-Renders verhindern und sicherstellen, dass deine Komponente nicht zum falschen Zeitpunkt unmounted.

Herzlichen Glückwunsch. Du hast gerade 300 Kilobyte JavaScript ausgeliefert – nur um einen Punkt auf der Einkaufsliste abzuhaken.

Das ist der aktuelle Stand der Dinge. Und irgendwie haben wir uns alle eingeredet, dass das normal ist.

Was ist HTMX eigentlich?

HTMX ist kaum eine Library zu nennen. Es sind gerade mal 14 Kilobyte. Das war's. 14 Kilobyte, um dynamisches Verhalten zu deinem HTML hinzuzufügen – ohne eine einzige Zeile JavaScript schreiben zu müssen.

Die Kernidee ist geradezu lächerlich simpel: HTML-Elemente können Requests auslösen und Teile der Seite aktualisieren. Das ist nicht revolutionär. Das ist buchstäblich so, wie das Web funktionieren sollte – bevor wir uns entschieden haben, alles in JavaScript zu bauen und komplette Anwendungen an den Browser zu schicken.

Ein einfaches Beispiel

Du willst einen Button, der mehr Inhalte nachlädt, ohne die Seite neu zu laden? Hier ist der Code:

<button hx-get="/load-more" hx-target="#content">Mehr laden</button>
<div id="content"></div>

Das war's. Kein State-Management. Kein useEffect. Kein Mounting-Lifecycle. Nur zwei HTML-Attribute und du bist fertig.

Wenn dieser Button geklickt wird, macht HTMX einen GET-Request an /load-more, nimmt die HTML-Antwort und packt sie in das #content-Div. Dein Server sendet HTML. Dein Browser zeigt HTML an. So wie Webanwendungen 20 Jahre lang funktioniert haben – bevor wir alles verkompliziert haben.

Warum das jetzt wichtig ist

In der Webentwicklung hat sich etwas verschoben. Nach Jahren des All-in auf Single Page Applications merken Entwickler, dass wir die Dinge vielleicht – nur vielleicht – zu kompliziert gemacht haben.

Laut GitHub-Statistiken von Anfang 2025 hat HTMX inzwischen mehr Sterne als Svelte und holt gegenüber Vue auf. Das liegt nicht an Marketing-Budget oder Konzernunterstützung. Es liegt daran, dass Entwickler müde sind.

Müde von 45-Sekunden-Build-Zeiten. Müde vom Debuggen von Hydration-Errors. Müde davon, dieselben CRUD-Operationen an drei verschiedenen Stellen zu schreiben. Müde von Frameworks, die Frameworks brauchen, um richtig zu funktionieren.

HTMX steht für etwas anderes. Es ist eine Rückkehr zu server-gerendertem HTML mit gerade genug Interaktivität, um modern zu wirken. Und es stellt sich heraus: Für eine riesige Anzahl von Anwendungen ist das alles, was du wirklich brauchst.

HTMX 4: Was kommt auf uns zu?

Die HTMX-Community arbeitet derzeit an Version 4.0 – und ja, du hast richtig gelesen: Es gibt keine Version 3. Carson Gross, der Erfinder von HTMX, hatte versprochen, dass es niemals eine Version 3 geben würde. Technisch gesehen hat er nicht gelogen – er springt einfach direkt zu Version 4.

Die wichtigsten Neuerungen in HTMX 4

Der größte technische Wandel ist der Wechsel von XMLHttpRequest zu der modernen fetch() API. Das klingt nach einem internen Detail, hat aber weitreichende Auswirkungen:

Natives Streaming: Mit fetch() unterstützt HTMX 4 Streaming-Responses direkt aus der Box. Server-Sent Events (SSE) sind ebenfalls wieder im Kern integriert.

Explizite Vererbung: In HTMX 2.0 wurden Attribute implizit vererbt, ähnlich wie bei CSS. Das war mächtig, aber auch verwirrend. In Version 4 musst du Vererbung explizit kennzeichnen, zum Beispiel mit hx-target:inherited.

Verbessertes History-Handling: Die alte Methode, DOM-Snapshots im localStorage zu speichern, ist Geschichte. HTMX 4 macht bei der Navigation einfach einen neuen Request – simpel und zuverlässig.

Morph-Swapping eingebaut: Der Idiomorph-Algorithmus, bisher nur als Extension verfügbar, ist jetzt Teil des Kerns. Damit lassen sich DOM-Änderungen intelligent mergen.

Die finale Version wird voraussichtlich Anfang bis Mitte 2026 erscheinen. Bis dahin bleibt Version 2.0 der Standard – und wird auch danach unbegrenzt unterstützt.

HTMX in der Praxis: Ein kleines Tutorial

Genug Theorie. Lass uns die Werkstatt betreten und etwas Konkretes bauen. Wir erstellen einen kleinen Kontaktbereich, der dynamisch Inhalte nachlädt, Formulare absendet und Feedback anzeigt – alles ohne JavaScript zu schreiben.

Schritt 1: HTMX einbinden

Füge einfach das Script in deinen HTML-Head ein:

<head>
  <script src="https://unpkg.com/htmx.org@2.0.4"></script>
</head>

Das war's. Kein npm install, kein Build-Prozess, kein node_modules-Ordner.

Schritt 2: Dynamisches Laden von Inhalten

Sagen wir, du hast eine Kontaktliste, die du bei Bedarf laden möchtest:

<div id="kontakt-bereich">
  <button hx-get="/api/kontakte" hx-target="#kontakt-liste" hx-swap="innerHTML">
    Kontakte laden
  </button>
  <ul id="kontakt-liste">
    <!-- Hier landen die Kontakte -->
  </ul>
</div>

Dein Server muss bei /api/kontakte einfach HTML zurückgeben:

<li>Max Mustermann - max@beispiel.de</li>
<li>Erika Musterfrau - erika@beispiel.de</li>
<li>Hans Schmidt - hans@beispiel.de</li>

HTMX kümmert sich um den Rest. Request abschicken, Antwort empfangen, in das Ziel-Element einfügen.

Schritt 3: Formulare ohne Page-Reload

Jetzt wird es interessant. Ein Kontaktformular, das ohne Seitenneuladen funktioniert:

<form hx-post="/api/kontakt/neu" hx-target="#feedback" hx-swap="innerHTML">
  <input type="text" name="name" placeholder="Name" required />
  <input type="email" name="email" placeholder="E-Mail" required />
  <button type="submit">Speichern</button>
</form>
<div id="feedback"></div>

Der Server verarbeitet die Formulardaten und gibt HTML zurück – zum Beispiel eine Erfolgsmeldung:

<p class="success">Kontakt wurde erfolgreich gespeichert!</p>

Schritt 4: Ladeanimationen hinzufügen

Für eine bessere User Experience kannst du Lade-Indikatoren einbauen:

<button
  hx-get="/api/kontakte"
  hx-target="#kontakt-liste"
  hx-indicator="#spinner"
>
  Kontakte laden
</button>
<span id="spinner" class="htmx-indicator">Lädt...</span>

Das htmx-indicator-Element wird automatisch sichtbar, während der Request läuft, und wieder versteckt, wenn die Antwort da ist. Dafür brauchst du nur etwas CSS:

.htmx-indicator {
  display: none;
}
.htmx-request .htmx-indicator {
  display: inline;
}

Schritt 5: Inline-Bearbeitung

Richtig praktisch wird es bei Inline-Editing. Ein Klick auf einen Namen, und er wird editierbar:

<span hx-get="/api/kontakt/1/edit" hx-trigger="click" hx-swap="outerHTML">
  Max Mustermann
</span>

Der Server gibt ein Formular zurück, das den Span ersetzt:

<form hx-put="/api/kontakt/1" hx-swap="outerHTML">
  <input type="text" name="name" value="Max Mustermann" />
  <button type="submit">Speichern</button>
</form>

Nach dem Speichern kommt wieder der Span zurück. Kein JavaScript nötig.

Die Hotwire-Verbindung

Falls du aus der Rails-Welt kommst, klingt das alles wahrscheinlich bekannt. DHH und das Basecamp-Team pushen diesen Ansatz seit Jahren mit Turbo und Stimulus, zusammen bekannt als Hotwire.

HTMX ist im Grunde die framework-agnostische Version derselben Philosophie. Nutze jede beliebige Backend-Sprache. Sende HTML über die Leitung. Behalte deine Server-Logik auf dem Server, wo sie hingehört.

Und hier ist der entscheidende Punkt: Basecamp läuft auf diesem Ansatz. Hey läuft darauf. Das sind echte Anwendungen, die Millionen von Nutzern bedienen. Das ist nicht theoretisch. Es funktioniert im großen Maßstab.

Wofür HTMX wirklich gut ist

Ich werde nicht so tun, als wäre HTMX für alles perfekt. Ist es nicht. Wenn du Google Docs oder Figma baust, brauchst du ein schwergewichtiges Frontend-Framework. Diese Apps leben im Browser, und das ist okay.

Aber wie viele Webanwendungen sind tatsächlich so? Das meiste, was wir bauen, ist CRUD. Create, Read, Update, Delete. Formulare, Tabellen, Dashboards, Admin-Panels. Zeug, das ehrlich gesagt vor 15 Jahren als server-gerendertes HTML großartig funktioniert hat.

HTMX glänzt bei:

• Content-Management-Systemen, in denen Admins Daten bearbeiten
• E-Commerce-Seiten mit Warenkörben und Checkouts
• SaaS-Dashboards mit Formularen und Tabellen
• Internen Tools und Admin-Panels
• Marketing-Seiten, die nur ein bisschen Interaktivität brauchen

Im Grunde: Wenn deine App hauptsächlich Daten anzeigt und Formulare abschickt, wird HTMX wahrscheinlich großartig funktionieren. Und das deckt einen überraschend großen Teil der Webentwicklung ab.

Die echte Developer Experience

Lass mich erzählen, wie es sich wirklich anfühlt, mit HTMX zu bauen, nachdem man Jahre in React-Land verbracht hat.

Das Gute

Du kannst Features unglaublich schnell bauen. Kein Boilerplate. Keine Konfiguration. Einfach Attribute zum HTML hinzufügen.

Debugging ist straightforward. Der Server gibt HTML zurück, der Browser zeigt es an. Das ist das gesamte Modell.

Deine Backend-Entwickler können tatsächlich zum Frontend beitragen, weil es nur HTML-Templates sind.

Deploy anywhere. Kein Build-Prozess bedeutet, du kannst buchstäblich eine Template-Datei bearbeiten und refreshen. Fertig.

Das Seltsame

Dein Gehirn braucht eine Umstellung. Nach Jahren von "Client-Side-State ist König" fühlt sich die Rückkehr zu server-getriebenen Updates anfangs komisch an.

Du wirst dich dabei erwischen, mehr nach JavaScript zu greifen als nötig. Manchmal ist ein HTMX-Attribut alles, was du brauchst.

Die Dokumentation könnte besser sein. Die offiziellen Docs sind okay, aber es gibt noch nicht tonnenweise Tutorials.

Das Frustrierende

Komplexe UI-Interaktionen brauchen immer noch JavaScript. HTMX ist keine Magie.

Wenn dein Backend langsam ist, fühlt sich alles langsam an. Du kannst Geschwindigkeit nicht mehr mit Loading-Skeletons vortäuschen.

Manche Entwickler werden dich verurteilen. Ja, wirklich. Mir wurde schon gesagt, HTMX sei "ein Rückschritt". Sie liegen falsch, aber sie sind laut.

Ist das wirklich die Zukunft?

Vielleicht. Vielleicht auch nicht. Aber es ist definitiv eine Zukunft.

Das Pendel der Webentwicklung schwingt. Wir sind von server-gerendert zu allem zu client-gerendert zu allem gegangen. Jetzt schwingen wir zurück zur Mitte. Server-Side-Rendering ist wieder cool. Edge-Computing macht Server-Responses schneller. Tools wie HTMX machen es einfach, Interaktivität ohne die Komplexität hinzuzufügen.

Wird HTMX React ersetzen? Nein. Werden manche React-Apps mit HTMX besser bedient sein? Absolut. Und je mehr Entwickler es ausprobieren und merken, wie viel einfacher es sein kann, desto größer wird dieser Anteil wahrscheinlich.

Fazit: Solltest du es ausprobieren?

Wenn du ein neues Projekt startest und es nicht irgendeine verrückte Echtzeit-Kollaborations-Sache ist – ja, ehrlich gesagt. Gib HTMX eine Woche lang eine Chance. Vielleicht wirst du es hassen. Aber vielleicht entdeckst du auch, dass du all dieses JavaScript gar nicht brauchst.

Das Beste daran? Du kannst klein anfangen. Füge HTMX zu einer Seite hinzu. Zu einem Feature. Schau, wie es sich anfühlt. Du verpflichtest dich nicht dazu, deine gesamte Anwendung umzuschreiben. Teste es einfach an etwas Simplem.

Und wenn du entscheidest, dass es nichts für dich ist, ist das völlig okay. Zumindest wirst du verstehen, warum manche von uns begeistert davon sind, Webanwendungen so zu bauen, wie wir es früher getan haben – nur mit besseren Werkzeugen.

Häufig gestellte Fragen

Kann ich HTMX mit meinem bestehenden Backend verwenden?

Ja, das ist einer der größten Vorteile von HTMX. Es ist komplett backend-agnostisch. Egal ob du Python mit Flask oder Django, PHP mit Laravel, Ruby on Rails, Node.js mit Express oder sogar Go verwendest – solange dein Server HTML-Fragmente zurückgeben kann, funktioniert HTMX damit.

Du musst keine API-Endpoints bauen, die JSON zurückgeben. Stattdessen renderst du einfach HTML-Templates auf dem Server und schickst sie als Response. Das vereinfacht die Architektur erheblich, weil du keine separate Frontend-Anwendung mehr pflegen musst.

Wie verhält sich HTMX in Bezug auf SEO und Barrierefreiheit?

HTMX hat hier einen natürlichen Vorteil gegenüber klassischen SPAs. Da der Server vollständiges HTML ausliefert, können Suchmaschinen deine Inhalte problemlos indexieren – ohne dass du Server-Side-Rendering oder Pre-Rendering konfigurieren musst. Bei der Barrierefreiheit sieht es ähnlich gut aus: HTMX arbeitet mit nativem HTML, was bedeutet, dass Screenreader und andere assistive Technologien den Inhalt normal verarbeiten können.

Allerdings solltest du bei dynamischen Inhalten darauf achten, ARIA-Live-Regions zu nutzen, damit Nutzer von Screenreadern über Änderungen informiert werden. Die Kombination aus semantischem HTML und den eingebauten HTMX-Attributen macht es insgesamt einfacher, barrierefreie Anwendungen zu bauen als mit vielen JavaScript-Frameworks.

Lohnt sich der Umstieg auf HTMX 4, wenn ich gerade erst mit Version 2 angefangen habe?

Für den Moment würde ich bei Version 2.0 bleiben und in Ruhe lernen. HTMX 4.0 befindet sich noch in der Alpha-Phase und wird frühestens Anfang bis Mitte 2026 als stabile Version erscheinen. Die gute Nachricht: Die grundlegenden Konzepte und die meiste Syntax bleiben gleich. Was du jetzt mit HTMX 2 lernst, ist nicht verschwendet. Wenn Version 4 dann stabil ist, werden die meisten Anpassungen eher kosmetischer Natur sein – neue Event-Namen, explizite Vererbung und ähnliches.

Das HTMX-Team hat zudem angekündigt, dass Version 2.0 unbegrenzt unterstützt wird. Du hast also keinen Zeitdruck. Konzentriere dich darauf, die Grundlagen zu verstehen, und halte ein Auge auf die Entwicklung von Version 4.