JPKCom DB

Die htmx-Reihe: HTML übers Netz, eingeordnet, gemessen, geprüft

Übersicht über meine dreiteilige htmx-Reihe: Einordnung gegen Unpoly und native Mittel, Sichtbarkeit für Crawler und KI, Barrierefreiheit. Mit Live-Demo.

von ·

htmx (öffnet in neuem Tab) verspricht moderne Oberflächen ohne JavaScript-Framework: Der Server liefert HTML, und ein paar Attribute tauschen Teile der Seite aus. Über die Idee ist viel geschrieben worden. Ich wollte wissen, wie sie sich in der Praxis anfühlt, und vor allem, was sie für zwei Themen bedeutet, die mir wichtig sind: die Sichtbarkeit für Suchmaschinen und KI-Systeme und die Barrierefreiheit. Diese Seite ist der Einstieg und das Inhaltsverzeichnis der Reihe.

Warum eine Reihe, die misst

Ich hatte htmx vor dieser Reihe in keinem Projekt eingesetzt. Statt eine Meinung aufzuschreiben, habe ich deshalb eine Demo gebaut und an ihr gemessen: einen fiktiven Veranstaltungskalender, robust mit htmx, mit Unpoly und ganz ohne Bibliothek, dazu einmal bewusst fragil mit htmx. Jeder Inhaltsblock trägt eine Prüfmarke, an der sich ablesen lässt, wer ihn zu sehen bekommt. Die Demo ist live, und jede Messung der Reihe kannst du dort nachprüfen: Demo: Veranstaltungskalender.

Die Reihe

  1. htmx eingeordnet: HTML übers Netz statt JSON: Was htmx ist, dieselbe Funktion in htmx, Unpoly und ohne Bibliothek, Turbo, Datastar und fixi im Kurzporträt, Stolpersteine mit CSP und eval und eine Entscheidungshilfe.
  2. Was Crawler und KI von htmx-Inhalten sehen: eine Messung: Prüfmarken per curl, im Headless-Browser und mit einem KI-Assistenten gemessen. Warum load, revealed und Buttons mit hx-get für KI-Crawler unsichtbar bleiben und wie robuste URLs das Problem lösen.
  3. htmx und Barrierefreiheit: was beim Austausch von HTML verloren geht: Mit der Tastatur durch vier Fassungen. Wohin der Fokus fällt, warum Titel und Sprache falsch werden können, was Unpoly und <dialog> dir abnehmen und was das BFSG damit zu tun hat.

Die wichtigsten Ergebnisse

  • htmx ist klein und frei: Die minifizierte Datei hat mit gzip 16.838 Byte, keine Abhängigkeiten, 0BSD-Lizenz. Unpoly bringt mehr fertige Bausteine mit, und sein JavaScript ist knapp dreieinhalbmal so groß.
  • Sichtbar ist, was in der ersten Antwort steht. Solange jeder Zustand eine echte URL hat, stand in meiner Messung alles in der ersten Antwort, auch für curl und einen KI-Assistenten. Was htmx per JavaScript nachlädt, sehen die meisten KI-Crawler nicht.
  • Barrierefreiheit bleibt deine Aufgabe. In der robusten Demo fiel der Fokus nach Tab-Wechsel und „Mehr laden" auf <body>, htmx übernahm fremde Seitentitel und ließ die Sprachauszeichnung stehen. Für alles gibt es in htmx eine Stellschraube, aber nur, wenn du davon weißt.

Für wen sich das lohnt

Wenn du serverseitig gerenderte Anwendungen baust und überlegst, sie mit wenig JavaScript lebendiger zu machen, ist Teil 1 der Einstieg. Wenn dich interessiert, ob deine Inhalte in KI-Antworten auftauchen können, lies Teil 2. Wenn deine Anwendung unter das BFSG fällt oder du einfach willst, dass sie für alle bedienbar ist, führt kein Weg an Teil 3 vorbei.

Weiterlesen

Die Referenz ist die Dokumentation auf htmx.org (öffnet in neuem Tab), die Idee dahinter erklärt das frei lesbare Buch „Hypermedia Systems" (öffnet in neuem Tab). Thematisch verwandt sind aus diesem Blog Schreiben für KI und Was ist GEO? zur Sichtbarkeit in KI-Antworten sowie HTML-Landmarks in der Praxis zur Barrierefreiheit der Seitenstruktur.