Direkt zum Inhalt

Was ist HTMX & Wie es für serverseitig gesteuerte Weboberflächen funktioniert?

AI-Translated

„HTML wurde entwickelt, um Benutzerinteraktionen zu erklären. HTMX verlagert dieses Verhalten zurück an seinen Ursprung, das Markup selbst."

Dies wirft eine grundlegende Frage auf: Was ist HTMX, und wie verändert sein servergesteuerter Ansatz die moderne Webentwicklung?

Um das zu beantworten, müssen wir einen Schritt zurückgehen und uns ansehen, wie das Web ursprünglich funktionierte.

Webbrowser basierten ursprünglich auf einem Modell, bei dem der Server HTML erzeugte und der Browser es rendert, Formulare übermittelt und Links navigiert wurden. Das war der Vertrag. Irgendwann entschied die Branche, dass Interaktivität JavaScript erforderte, um alles abzufangen, die Benutzeroberfläche aus JSON-Payloads zu konstruieren und ein paralleles Modell des Anwendungszustands auf dem Client aufrechtzuerhalten. Es fühlte sich wie Fortschritt an. Es fügte aber auch erhebliches Gewicht hinzu.

HTMX vertritt eine ziemlich pointierte These: Der größte Teil des von Ihnen geschriebenen JavaScript hätte auf dem Server bleiben können.

Das ist entweder eine Erleichterung oder eine Provokation, je nachdem, wo man steht. Aber es lohnt sich, dies genau zu prüfen, denn für eine große Kategorie von realen Projekten hat HTMX gute Argumente.

Was ist HTMX?

Es gibt eine kleine JavaScript-Bibliothek von kaum 14 Kilobyte, die sich still und leise zu einem der umstrittensten Tools in der modernen Webentwicklung entwickelt hat. Sie führt kein neues Komponentenmodell ein. Sie erfordert keine Build-Pipeline. Sie wird Sie nicht bitten, etwas von npm zu installieren.

HTMX ist eine Bibliothek, die HTML um Attribute erweitert, um HTTP-Anfragen zu stellen, Teile einer Seite zu aktualisieren und Ereignisse zu verarbeiten, alles ohne selbst JavaScript schreiben zu müssen. Eine Handvoll hx-* Attribute in Ihrem Markup, und Ihr serverseitig gerendertes HTML wird interaktiv. Kein React. Kein State Management. Keine Orchestrierungsschicht zwischen Ihren Daten und Ihrer Benutzeroberfläche.

Die Attribute sind bewusst lesbar gestaltet. hx-get löst eine GET-Anfrage aus. hx-target gibt an, wohin die Antwort geht. hx-trigger definiert, wann es passiert. Ein Vokabular, das klein genug ist, um es sich zu merken, und ausdrucksstark genug, um die meisten Fälle abzudecken.

php · HTMX class example 
(new Htmx()) 
    ->post($form_url) 
    ->onlyMainContent() 
    ->select('#source-dependent')
    ->target('#source-dependent')
    ->swap('outerHTML')
    ->applyTo($form['source_dependent']['source']);

HTMX vs. AJAX: Hauptunterschiede in der Webentwicklung

Betrachten Sie ein bekanntes Szenario: einen Kategoriefilter, der eine Inhaltsliste aktualisiert, ohne die Seite neu zu laden. Bei traditionellem AJAX sieht die Abfolge so aus: Ein JavaScript-Event-Listener wird ausgelöst, fetch() sendet eine Anfrage, der Server gibt JSON zurück, JavaScript parst dieses JSON, erstellt DOM-Elemente und aktualisiert die Seite. Fünf Übersetzungsschritte zwischen dem, was der Server weiß, und dem, was der Benutzer sieht.

Traditioneller AJAX-Fluss HTMX-Fluss
JS-Event-Listener wird ausgelöst hx-trigger wird ausgelöst
fetch() oder axios sendet eine Anfrage Der Browser sendet eine GET-Anfrage
Server gibt JSON zurück Server gibt HTML zurück
JS parst JSON HTMX platziert HTML im Ziel
JS erstellt DOM-Elemente -
JS aktualisiert die Seite -

Und das JavaScript, das Sie für AJAX schreiben müssten:

php · Drupal AJAX (the old way)
$form['source_dependent']['source'] = [
    '#type'  => 'select',
    '#title' => $this->t('Source'),
    '#ajax'  => [
        'callback' => '::updateSourceDependent',
        'event'    => 'change',
        'wrapper'  => 'source-dependent-wrapper',
    ],
];

Vergleichen Sie das mit HTMX:

php · HTMX (the new way)
(new Htmx())
    ->post($form_url)
    ->onlyMainContent()
    ->select('#source-dependent')
    ->target('#source-dependent')
    ->swap('outerHTML')
    ->applyTo($form['source_dependent']['source']);

Der AJAX-Ansatz fragt „Welche Daten haben sich geändert?“ und HTMX fragt „Wie soll dieser Abschnitt jetzt aussehen?

Der Hauptunterschied zwischen HTMX und AJAX besteht darin, dass AJAX auf JavaScript angewiesen ist, um JSON zu verarbeiten und das DOM zu aktualisieren, während HTMX es dem Server ermöglicht, fertig gerendertes HTML zurückzugeben, wodurch die Frontend-Komplexität reduziert und die Wartbarkeit verbessert wird.

HTMX-Beispiele und Attribute erklärt

Sie müssen sich nicht die vollständige API merken. Diese decken die meisten realen Anwendungsfälle ab:

Attribut Zweck Beispiel
hx-get / hx-post / hx-put / hx-delete Zu verwendende HTTP-Methode: get, post, update und delete hx-delete="/term/42"
hx-trigger Wann die Anfrage ausgelöst wird key up changed delay: 300ms
hx-target Wohin die HTML-Antwort geht #results, closest tr
hx-swap Wie HTML eingefügt wird innerHTML, outerHTML
hx-include Zusätzliche Formularwerte zum Senden closest form
hx-confirm Bestätigungsdialog hx-confirm="Sure?"
hx-indicator Ladeelement anzeigen #loading-spinner

Das Attribut hx-trigger unterstützt leistungsstarke Modifikatoren. Zum Beispiel wird keyup changed delay: 300ms nur 300ms nachdem der Benutzer aufgehört hat zu tippen und nur wenn sich der Wert tatsächlich geändert hat, ausgelöst – ein perfektes Debounce für die Live-Suche ohne zusätzlichen Code.

HTMX in Drupal verwenden: Integration in Drupal 11.3

Drupal ist bereits ein serverseitig gerendertes Framework. Es generiert HTML mithilfe von Twig-Templates, leitet Anfragen über Controller und verwaltet Assets über ein Bibliothekssystem. Diese Architektur macht die HTMX-Integration in Drupal sowohl natürlich als auch effizient, da sie sich nahtlos in die Kernmuster von Drupal einfügt, ohne unnötige Frontend-Komplexität einzuführen.

Die HTMX-Unterstützung wurde erstmals in Drupal 11.2 eingeführt und ist in Drupal 11.3 voll funktionsfähig, mit einer nativen HTMX-Klasse, die die Bibliotheksanbindung und Attributkonstruktion in einem einzigen fließenden Aufruf handhabt. Frühe Anwender der Drupal HTMX-Integration haben Reduzierungen der JavaScript-Payloads um bis zu 71 % gemeldet, was die Effektivität bei der Optimierung der Frontend-Leistung unterstreicht.

Mit HTMX in Drupal 11.3 können Entwickler dynamische, serverseitig gerenderte Schnittstellen erstellen, ohne stark auf JavaScript-Frameworks angewiesen zu sein. Dieser Ansatz macht die HTMX-Drupal-Integration besonders gut geeignet für Admin-Panels, Content-Workflows und dynamische Filtersysteme, bei denen Einfachheit, Wartbarkeit und Leistung entscheidend sind.

1. HTMX über das Bibliothekssystem laden

Drupal 11.3+: Verwendung der Core Htmx-Klasse

Wie Sie HTMX laden, hängt von Ihrer Drupal-Version ab. Drupal 11.3+ HTMX wird mit dem Core ausgeliefert. Verwenden Sie die native HTMX-Klasse, die die Bibliothek anhängt und alle Attribute in einem Schritt erstellt:

php · Drupal 11.3+ (core Htmx class)
use Drupal\Core\Htmx\Htmx;
(new Htmx())
    ->post($form_url)
    ->onlyMainContent()
    ->select('#source-dependent')
    ->target('#source-dependent')
    ->swap('outerHTML')
    ->applyTo($form['source_dependent']['source']);

Drupal 10 / 11 (unter 11.3): Manuelle Bibliotheksregistrierung

Bei älteren Versionen ist HTMX nicht Teil des Cores. Registrieren Sie es als externe Bibliothek in libraries.yml und wenden Sie dann hx-*-Attribute direkt im #attributes-Schlüssel der Form API an:

yaml · libraries.yml
htmx:
    version: 1.x
    js:
        https://unpkg.com/[email protected]: { type: external, minified: true }

2. hx-* Attribute zu Ihren Formularelementen hinzufügen

In der Form API von Drupal werden benutzerdefinierte HTML-Attribute im Schlüssel #attributes abgelegt. HTMX-Attribute befinden sich hier genau wie jedes andere HTML-Attribut:

php · Form API (raw attributes, Drupal 10 / 11 below 11.3)
$form['vocab'] = [
    '#type'       => 'select',
    '#title'      => $this->t('Select Vocabulary'),
    '#options'    => $options,
    '#attributes' => [
        'hx-get'     => $terms_url,
        'hx-trigger' => 'change',
        'hx-target'  => '#terms-wrapper',
        'hx-include' => 'closest form',

    ],
];
$form['search'] = [
    '#type'       => 'textfield',
    '#title'      => $this->t('Search terms'),
    '#attributes' => [
        'hx-get'     => $terms_url,
        'hx-trigger' => 'keyup changed delay:300ms',
        'hx-target'  => '#terms-wrapper',
        'hx-include' => 'closest form',
        'placeholder'=> 'Search...',
    ],
];

hx-include="closest form" ist das Wichtigste; es weist HTMX an, alle Formularwerte mit jeder Anfrage zu senden, einschließlich der versteckten CSRF-Tokens von Drupal. Ohne dies wird nur der Wert des auslösenden Elements gesendet, und Ihre Filter werden nicht übernommen.

3. HTML von Ihrem Controller zurückgeben

Die Route, auf die Ihr hx-get zeigt, muss HTML zurückgeben, nicht eine vollständige Drupal-Seite. Ein normaler Controller, der ein Render-Array zurückgibt, tut genau dies:

php · controller
public function loadTerms(Request $request) {
    $vid    = $request->query->get('vocab');
    $search = $request->query->get('search');
    // ... query your data ...
    // Drupal renders this, HTMX receives the HTML
    return [
        '#theme' => 'your_template',
        '#terms' => $terms,
    ];
}

Drupal handhabt Routing, Berechtigungen, Rendering und Caching genau wie gewohnt. HTMX entscheidet lediglich, welcher Teil der Seite wann aktualisiert wird.

So überprüfen Sie, ob HTMX funktioniert: Öffnen Sie die DevTools → Registerkarte „Netzwerk“ → interagieren Sie mit dem Formular. Sie sehen eine Anfrage wie:

How to Verify HTMX is Working and What is HTMX OpenSense labs

Vor- und Nachteile: Die ehrliche Einschätzung

Wo HTMX wirklich hilft?

  1. Deutlich weniger JavaScript. Bei serverseitig gerenderten Anwendungen besteht ein erheblicher Teil von JS lediglich darin, Daten zu verschieben und das DOM zu aktualisieren. HTMX eliminiert den größten Teil davon.
  2. Das Debugging ist transparent. Jede HTMX-Anfrage erscheint im Netzwerk-Tab als normale HTTP-Anfrage. URL, Parameter, HTML-Antwort, alles sichtbar.
  3. Schnellere Entwicklung für CRUD-Schnittstellen. Admin-Panels, Content-Workflows, filterlastige Listen – HTMX bewältigt diese schneller als die Einrichtung eines Frontend-Frameworks und einer API-Schicht.
  4. Natürliche Passung für Server-Frameworks. Drupal, Laravel, Django, Rails – wenn Ihr Framework bereits Templates rendert, passt HTMX zur bestehenden Architektur.
  5. Geringerer Wartungsaufwand im Laufe der Zeit. Weniger JavaScript bedeutet weniger Abhängigkeiten, weniger störende Upgrades und eine einfachere Einarbeitung für neue Entwickler.

Wo HTMX Schwächen zeigt?

  1. Nicht für komplexe clientseitige Zustände konzipiert. Wenn Ihre Benutzeroberfläche Interaktionen lokal verfolgen muss, wie Drag-and-Drop-Builder, mehrstufige Formulare mit Verzweigungslogik und Echtzeit-Zusammenarbeit, wird HTMX Sie dazu zwingen, dafür zu arbeiten.
  2. Jede Interaktion erfordert einen Server-Roundtrip. Für die meisten Admin-Tools ist das in Ordnung. Für alles, was eine sofortige, Offline- oder unter 50 ms liegende Antwort benötigt, werden Sie die Latenz spüren.
  3. Der Server wird für die UI-Struktur verantwortlich. Das ist eigentlich der Punkt, erfordert aber einen mentalen Wandel. Ihr Backend-Team muss darüber nachdenken, welches HTML zurückgegeben werden soll, nicht nur welche Daten.
  4. Die Animationssteuerung ist begrenzt. Sanfte Übergänge erfordern zusätzliche CSS-Arbeit. HTMX verfügt über kein integriertes Animationssystem.

Das Fazit

HTMX ist eher eine Korrektur. Irgendwann entschied die Branche, dass Interaktivität JavaScript-lastige Frontends bedeutete, selbst für Anwendungen, die im Grunde serverseitig gerendert wurden, Admin-Panels, Content-Workflows und filterlastige CRUD-Schnittstellen. Diese Annahme blieb jahrelang weitgehend unhinterfragt.

HTMX hinterfragt dies. Und für eine große Kategorie dessen, was tatsächlich täglich gebaut wird, lautet die Antwort: Sie hätten diese Komplexität vielleicht gar nicht gebraucht. Sie brauchten eine Bibliothek, die Ihr HTML etwas mehr tun ließ.

Was ist HTMX also in der Praxis?

Es ist ein leichter Ansatz zum Erstellen dynamischer, servergesteuerter Weboberflächen, ohne stark auf JavaScript-Frameworks angewiesen zu sein.

Es wird React nicht für komplexe zustandsbehaftete Anwendungen ersetzen. Aber für die Admin-Panels und Content-Workflows, die einen Großteil dessen ausmachen, was gebaut wird? Es entfernt eine Komplexitätsebene, die Sie vielleicht gar nicht erst gebraucht hätten.

Das ist ein bescheidenes Versprechen. Aber in einem Ökosystem, in dem Bescheidenheit und Ehrlichkeit selbst Mangelware sind, ist es ernst zu nehmen.

Möchten Sie Ihr Frontend vereinfachen und servergesteuerte Schnittstellen mit HTMX in Drupal erstellen? Wir helfen Ihnen, es richtig umzusetzen.

Sprechen Sie mit unseren Drupal-Expert:innen

Referenzen:

Abonnieren

Ready to start your digital transformation journey with us?

Loading form...