Seite 2: APIs: JSON, XML oder etwa HTML?

Inhaltsverzeichnis

Das bedeutet, HTMX arbeitet im Kern nicht mit einer klassischen API zusammen, sondern der Server muss speziell für HTMX um Routen erweitert werden, die fertiges HTML zurückgeben. Folglich hebt HTMX die Trennung von Präsentation und Daten auf – es sei denn, man entwickelt ein dediziertes Backend für HTMX. Das entspräche dem Ansatz des BFF-Patterns (Backend For Frontend), bedeutet aber zugleich auch zusätzlichen Aufwand.

Optional ist es übrigens möglich, dass der Server komplette Seiten zurückgibt und HTMX clientseitig mittels eines Attributs angewiesen wird, nur einen Ausschnitt dieser Seite zu rendern. Das sichert Kompatibilität zu Backends, die vollständig serverseitig rendern. Allerdings ist das ziemlich ineffizient, da bei jedem Aufruf zunächst eine komplette Seite geladen werden muss, von der dann möglicherweise der Großteil umgehend wieder verworfen wird. HTMX arbeitet demnach ausschließlich mit HTML und nicht mit herkömmlichen APIs.

Damit komme ich zu meinem ersten Kritikpunkt: Dieser Ansatz verlangt, dass ich als Entwicklerin oder Entwickler das Backend an das Frontend anpassen muss. Aus meiner Sicht ist das eine eher schlechte Praxis, die man vermeiden sollte, sofern es keine wirklich guten Gründe dafür gibt. Es verletzt eine grundlegende Regel der Softwarearchitektur, nach der Abhängigkeiten stets von oben nach unten verlaufen sollten und nicht umgekehrt. Denn dadurch wird Ihr Backend faktisch an Ihr Frontend gebunden. Noch problematischer ist, dass Ihr Backend an die spezifische Wahl einer UI-Technologie gekoppelt wird, was grundsätzlich keine gute Idee ist.

Das BFF-Pattern

An dieser Stelle führen HTMX-Anhängerinnen und -Anhänger häufig das erwähnte BFF-Pattern (Backend For Frontend) an. Folgt man diesem Pattern, ist eine spezielle API für ein konkretes Frontend kein schlechter, sondern vielmehr sogar ein erstrebenswerter Ansatz. Ich sehe das zwiegespalten. Prinzipiell spricht nichts gegen das BFF-Pattern. Aber ich finde den Gedanken seltsam, ein zusätzliches Backend zu entwickeln, um eine Frontend-Bibliothek nutzen zu können, die vor allem damit beworben wird, dass alles so einfach sei und man kaum noch programmieren müsse. Tatsächlich verlagert das Pattern viel Aufwand und Komplexität in das Backend. Das ist legitim, aber damit ist es eben nicht mehr so einfach, HTMX "mal eben" zu verwenden – wie die Befürworter gerne implizieren.

Hinzu kommt, dass Sie um eine JSON-basierte API vermutlich kaum herumkommen werden, wenn Sie zusätzlich beispielsweise auch noch eine Mobile-App, eine Desktop-Anwendung oder andere Dienste anbinden möchten. Das missfällt mir. Da ich erwähnte, dass das Backend an HTMX als spezifische Technologie gebunden wird: HTMX erwartet in bestimmten Situationen spezielle, nicht standardisierte HTTP-Statuscodes, wie zum Beispiel den Statuscode 286, der HTMX-eigen ist. Sie werden diesen Statuscode nirgendwo anders finden oder nutzen können, was einfach keine gute Idee ist.

Proprietäres Wissen

HTMX zwingt Sie zudem dazu, sich eine weitere framework- oder bibliotheksspezifische, proprietäre Syntax aneignen zu müssen. Die von HTMX eingeführten Attribute und deren Wertestrukturen folgen nämlich ebenfalls keinem Standard. Das ist im Grunde das Gleiche, was bereits bei Technologien wie Knockout oder Angular 1 der Fall war. Wenn Sie in der Vergangenheit mit einer dieser Technologien gearbeitet haben, könnten Sie sich fragen: Hat Ihnen das Erlernen der spezifischen HTML-Attribute von Knockout oder Angular auf lange Sicht einen Nutzen gebracht? Können Sie das damals erworbene Wissen heute überhaupt noch nutzen?

Wenn nicht, warum sollte es mit der HTMX-spezifischen Syntax in ein paar Jahren anders sein? Kurz gesagt: Wenn HTMX nicht zum langfristigen Standard wird, investieren Sie Zeit und Mühe in etwas, das schon heute absehbar morgen überflüssig sein wird. Ich weiß nicht, wie Sie dazu stehen, aber auf mich wirkt das wenig ansprechend.

Weitere Bedenken

Zu den bereits genannten Punkten kommt hinzu, dass Sie mit den hx-Attributen technisch gesehen ungültiges HTML schreiben. Wenn Sie eine mit HTMX erstellte Webseite durch einen Validator laufen lassen, werden Sie zahlreiche Fehlermeldungen erhalten. Ich behaupte, dass beispielsweise Google es nicht besonders schätzt, wenn Webseiten offensichtlich kein syntaktisch valides HTML verwenden, was sich möglicherweise negativ auf das Suchmaschinenranking auswirken könnte. Technisch gesehen handelt es sich um Data-Attribute: Sie könnten also beispielsweise hx-post in data-hx-post umwandeln, um syntaktisch valides HTML zu erhalten. Aber wer tut das schon, insbesondere da auch die Dokumentation von HTMX und sämtliche Beispiele hier mit schlechtem Vorbild vorangehen?

Ferner sind Sie mit dem Problem der fehlenden Typsicherheit konfrontiert. Ein einziger Tippfehler genügt, Ihre Webseite lahmzulegen, woraufhin Sie manuell mit der Fehlersuche beginnen müssen. Das erinnert stark an die Erfahrungen mit Knockout: Ein Fehler im Data-Binding und nichts funktionierte mehr. Aber man erhielt auch keine Fehlermeldung, sondern nur eine nicht funktionierende Webseite. Sie können sich sicherlich vorstellen, wie wenig Vergnügen die Fehlersuche in solchen Fällen bereitet. Effektives Debugging ist praktisch nicht möglich. Zudem bieten die gängigen Editoren und IDEs (noch) keine Unterstützung für diese Syntax, was bedeutet, dass Ihnen Funktionen wie IntelliSense fehlen. Zwar könnten entsprechende Plug-ins Abhilfe schaffen, doch das grundlegende Problem der mangelhaften Debugging-Erfahrung bleibt.

Zum Thema Skalierbarkeit

Mit viel Wohlwollen könnte man sagen, dass HTMX bestenfalls für sehr kleine Webseiten geeignet ist. Allerdings gibt es so viele Aspekte, die HTMX für größere, komplexere Projekte vollkommen ungeeignet machen: HTMX missachtet bewährte Architekturprinzipien, widerspricht gängigen Standards, missachtet die Trennung von UI und Daten und legt dem Backend Restriktionen auf, weil das Frontend es so verlangt. Es lässt sich nicht vernünftig debuggen oder testen.

Ich halte also nichts von HTMX. Aus meiner Perspektive ist es eine miserable Idee, auf HTMX zu setzen – es fühlt sich wie ein Rückschritt um zehn Jahre an.

Ich möchte damit nicht behaupten, dass React, Angular, Vue, Svelte oder irgendein anderes UI-Framework die unangefochtene Lösung für alles sei. Es gibt auch dort viele Kritikpunkte, die Frontend-Entwicklung ist insgesamt unnötig kompliziert geworden und es bedarf dringend einiger Veränderungen, um die Arbeit wieder spaßvoll und effizienter zu gestalten. Der Weg zu einer besseren Zukunft sollte jedoch über Standards führen und nicht über den nächsten proprietären Ansatz, der uns dazu verführt, uns erneut auf ein Framework zu verlassen, das in zehn Jahren niemand mehr kennt oder verwendet. Und wir sollten uns sicherlich nicht auf eine Lösung einlassen, die dieselben Fehler wiederholt, die wir bereits vor zehn Jahren gemacht haben. HTMX gehört zu den letzten Technologien, zu deren Einsatz ich raten würde.

Standards statt proprietäre Frameworks

Der richtige Ansatz besteht meiner Meinung nach darin, uns von der Notwendigkeit eines Frameworks oder einer Bibliothek zu lösen und stattdessen stärker auf Standards und native Web-Technologien zu setzen. Denn nur so können wir der Abhängigkeitsfalle entkommen. Wie genau dieser Weg aussehen wird, weiß auch ich noch nicht. Aber dass dies der Weg ist, den wir einschlagen sollten, davon bin ich überzeugt. In dieser Hinsicht hat sich bereits einiges getan. – wie ich in meinem Blogeintrag Vanilla-Web: Der Frontend-Trend 2024? ausgeführt habe.

Trotz aller ausgeführten Argumente kann es natürlich sein, dass Sie oder Ihr Team dennoch überzeugt sind, dass HTMX für Ihren speziellen Anwendungsfall geeignet sein könnte. In diesem Fall bitte ich Sie um einen Gefallen: Lassen Sie uns darüber sprechen, nehmen Sie Kontakt mit uns (www.thenativeweb.io) auf. Vielleicht stellen wir gemeinsam fest, dass HTMX tatsächlich in Ihrem speziellen Fall sinnvoll ist. (map)