Anmelden
Künstliche Intelligenz hat auch das World Wide Web erreicht.
(Bild: metamorworks/Shutterstock.com)
Braucht es für KI-Funktionen immer die Cloud? Nicht zwingend, denn KI-Modelle laufen auch direkt im Browser – gute Performance und viel Speicher vorausgesetzt.
Künstliche Intelligenz (KI) ist in aller Munde: Keine Woche vergeht ohne die Ankündigung eines neuen Produkts, Chatbots oder eines verbesserten KI-Modells. Zeitgleich hält generative KI in die großen Produktivitätsanwendungen Einzug: Adobe Photoshop erlaubt das Ersetzen von Objekten in einem Bild per einfacher Texteingabe [1] und in Office und Windows steht der Microsoft Copilot [2] dem Anwender zur Seite. Kein Wunder, dass auch viele Anwendungsentwickler derzeit beabsichtigen, generative KI in die eigene Anwendung zu bringen.
Bislang führt dieser Weg fast ausschließlich in die Cloud. Alle großen Cloudanbieter halten einfach verwendbare Schnittstellen bereit, um KI-Funktionen in die eigenen Anwendungen zu integrieren.
Doch das muss nicht zwingend so sein: Der KI-Trend hat auch das World Wide Web erreicht. Fast zeitgleich zum Hype wurde mit Chromium 113 (April 2023) die Schnittstelle WebGPU unter Windows und macOS verfügbar gemacht. Diese API gibt Webanwendungen einen Low-Level-Zugriff auf die Graphics Processing Unit (GPU) des Systems, die sich nicht nur für Grafikanwendungen, sondern auch für die erforderlichen Berechnungen im Bereich Machine Learning (ML) gut eignet. Darüber lassen sich ML-Modelle effizient im Browser ausführen.
Zwei Showcases von Machine Learning Compilation [3] machen von dieser Schnittstelle bereits Gebrauch:
Beide Showcases sind quelloffen, im Falle von WebLLM gibt es sogar das npm-Paket @mlc-ai/web-llm [6], das Entwickler in die eigene App integrieren können.
In beiden Fällen müssen die KI-Modelle zuerst auf das Endanwendergerät übertragen werden. Diese Modelle sind allerdings mehrere Gigabyte groß, sodass eine schnelle Internetverbindung ebemso erforderlich ist wie ausreichend viel Speicherplatz. Auch die Ausführung des Modells ist anspruchsvoll, setzt viel Arbeitsspeicher und Rechenleistung voraus.
Im Gegenzug sind die Modelle nach dem initialen Download auch offline oder bei unzuverlässiger Internetverbindung verfügbar. Die Daten verlassen das Gerät des Anwenders zudem nicht, sodass sich dieser Ansatz auch für kritische Daten eignet. Ferner fallen keine Kosten an, da die Modelle quelloffen sind. Allerdings sind kommerzielle Modelle wie OpenAI GPT-4 noch deutlich leistungsfähiger. Doch auch in diesem Bereich tut sich viel, und Open-Source-Modelle werden kontinuierlich besser – und kleiner.
Mit WebGPU ist das Ende der Fahnenstange zudem noch nicht erreicht: Die Web Neural Network API [7] (WebNN) befindet sich derzeit beim World Wide Web Consortium (W3C) in Spezifikation. Diese Schnittstelle wird die Ausführung von Machine-Learning-Modellen im Webbrowser noch einmal beschleunigen, indem sie Webanwendungen zusätzlich Zugriff auf die plattformspezifischen ML-Schnittstellen und somit auf die Neural Processing Unit (NPU) gewähren, sofern diese auf der Zielplattform verfügbar sind.
Schon heute lassen sich anspruchsvolle KI-Modelle direkt im Webbrowser verwenden. In Kombination mit den übrigen Schnittstellen aus dem Umfeld der Progressive Web Apps [8] lassen sich damit komplett offlinefähige KI-Webanwendungen bauen. Zweifelsohne steht diese Entwicklung aber noch ziemlich am Anfang: So befindet sich WebGPU in WebKit (Safari) und Gecko (Firefox) noch in Implementierung; auch in Chromium-basierten Browsern ist die Schnittstelle unter Android und Linux noch nicht verfügbar. WebNN ist noch in keinem Browser nutzbar.
KI in Webanwendungen dürfte aber zunehmend an Relevanz gewinnen: Zu viele Anwendungsfälle lassen sich mit klassischer regelbasierter Entwicklung nicht sinnvoll abdecken. Das Web geht dieser Entwicklung jedenfalls vorbereitet entgegen.
URL dieses Artikels:
https://www.heise.de/-7520733
Links in diesem Artikel:
[1] https://www.adobe.com/de/products/photoshop/generative-fill.html
[2] https://adoption.microsoft.com/de-de/copilot/
[3] https://mlc.ai/
[4] https://webllm.mlc.ai/
[5] https://websd.mlc.ai/
[6] https://www.npmjs.com/package/@mlc-ai/web-llm
[7] https://webmachinelearning.github.io/webnn-intro/
[8] https://www.heise.de/blog/Progressive-Web-Apps-Teil-1-Das-Web-wird-nativ-er-3733624.html
[9] mailto:rme@ix.de
Copyright © 2024 Heise Medien
(Bild: Diki Prayogo/ Shutterstock.com)
Die einen lieben HTMX, die anderen hassen es. Was ist dran am Hype um HTMX, was spricht für und was gegen die Bibliothek?
Eine Frage wird mir derzeit täglich gestellt. Von der Community, von Kunden, per E-Mail, telefonisch, auf Discord, in den Kommentaren und in persönlichen Gesprächen, um nur einige Beispiele zu nennen. Seit meinem kürzlich veröffentlichten Beitrag Vanilla Web: Der Frontend-Trend 2024? [1] hat das Interesse noch einmal spürbar zugenommen. Die Frage lautet: "Was ist Ihre Meinung zu HTMX?"
Diese Frage versuche ich aus meiner persönlichen Sicht umfassend und fundiert zu beantworten. Und falls Sie – was unwahrscheinlich, aber möglich ist – noch nie von HTMX gehört haben sollten: Lesen Sie diesen Blogeintrag dennoch. Ich bin überzeugt, dass auch in Ihrem Team früher oder später die Frage aufkommen wird: "Sollten wir uns nicht einmal HTMX genauer anschauen?" Damit Sie nicht völlig unvorbereitet sind, sondern bereits eine grobe Vorstellung haben, worum es bei HTMX geht, und um vielleicht auch das eine oder andere Argument parat zu haben, empfehle ich Ihnen die Lektüre der folgenden Zeilen.
HTMX ist eine kompakte Bibliothek für Web-Benutzeroberflächen und trug ursprünglich den Namen Intercooler.js. Mit der Einführung der Version 2 erfolgte die Umbenennung in HTMX [2], sodass HTMX 1.0 im Grunde Intercooler 2.0 entspricht. Der wesentliche Unterschied ist, dass sich HTMX als eine Neuentwicklung betrachten lässt, die – im Gegensatz zu Intercooler – nicht auf jQuery basiert. HTMX schlägt diesbezüglich einen neuen Weg ein.
Auf npm verzeichnet HTMX derzeit etwa 50.000 Downloads pro Woche. Zur Einordnung: Svelte erreicht knapp eine Million Downloads, Vue fast fünf Millionen und React über 20 Millionen. Warum HTMX dennoch keine Nischentechnik ist, werden wir später noch erläutern. Bis dahin ist es ratsam, bei der Interpretation der Download-Statistiken von HTMX auf npm eine gewisse Vorsicht walten zu lassen.
Was zeichnet HTMX im Vergleich zu anderen Technologien wie beispielsweise React aus? Der grundlegende Unterschied liegt in der Herangehensweise: HTMX setzt darauf, Web-Benutzeroberflächen weiterhin in HTML zu definieren, anstatt in JavaScript, wie es beispielsweise bei React der Fall ist. HTMX verfolgt eine HTML-zentrierte Architektur, im Gegensatz zu vielen anderen Bibliotheken und Frameworks, die sich auf JavaScript konzentrieren. Sie arbeiten also mit regulärem HTML und erweitern es durch spezielle, von HTMX definierte Attribute. Auf diese Weise lassen sich viele Standardaufgaben, für die sonst JavaScript erforderlich wäre, vollständig deklarativ in HTML realisieren.
Einige Entwicklerinnen und Entwickler betrachten diesen Ansatz als etwas völlig Neuartiges. Doch in Wahrheit ist das Konzept nicht neu. Ähnliche Ansätze gab es bereits in der Vergangenheit, wie zum Beispiel bei Knockout.js [4] im Jahr 2010. Auch Angular 1, die ursprüngliche Version von Angular, folgte diesem Prinzip im Jahr 2013. Interessanterweise stammt Intercooler, der Vorläufer von HTMX, ebenfalls aus dem Jahr 2013. Somit greift HTMX eine Denkweise auf, die etwa ein Jahrzehnt alt ist. Da viele Entwicklerinnen und Entwickler diese Phase entweder nicht selbst miterlebt oder sie schlicht vergessen haben, erscheint der Ansatz, HTML in den Vordergrund zu rücken und deklarativ zu erweitern, einigen nun als radikal anders und neuartig, obwohl er das faktisch nicht ist.
HTMX funktioniert im Kern durch den Einsatz benutzerdefinierter Attribute. Um ein einfaches Beispiel anzuführen: Stellen Sie sich ein div-Element vor, dem Sie das Attribut hx-post hinzufügen, konkret hx-post="/articles". Normalerweise würde der Browser dieses Attribut ignorieren, da er unbekannte HTML-Elemente und -Attribute üblicherweise nicht beachtet. HTMX jedoch belebt dieses Attribut: Wenn Sie auf das div klicken, wird dank HTMX im Hintergrund eine HTTP-POST-Anfrage an die URL /articles gesendet. Auf diese Weise kann jedes beliebige HTML-Element einen POST-Request auslösen, wobei dies meist durch Klicken geschieht. Bei Formularen wird ein Request üblicherweise durch das Absenden ausgelöst. So lässt sich jedes Element zur Interaktion mit dem Netzwerk nutzen. Diese Funktionalität beschränkt sich nicht nur auf POST-Requests, sondern umfasst auch GET, PUT und DELETE. Demnach kann jedes HTML-Element jede Art von HTTP-Request initiieren.
Nun stellt sich die Frage, was mit dem Ergebnis, also der vom Server zurückgesendeten Antwort, geschieht. HTMX fängt diese ab und setzt, um bei dem div-Beispiel zu bleiben, das Ergebnis als neuen Inhalt dieses div-Elements ein. Somit wird die Serverantwort direkt angezeigt. Optional kann das Ergebnis auch in einem anderen Element dargestellt werden. Hierfür verwendet man zusätzlich das Attribut hx-target und gibt als Wert einen CSS-Selektor an, der das Element bestimmt, in dem das Ergebnis erscheinen soll. Mit anderen Worten, HTMX ermöglicht es, mit nur zwei Attributen einen AJAX-Request auszuführen, ohne auch nur eine einzige Zeile JavaScript schreiben zu müssen.
Es ist auch möglich, das gesamte Element komplett zu ersetzen: Geben Sie einfach das hx-swap-Attribut an. Damit können Sie auswählen, wie das Ergebnis gerendert werden soll: als Inner- oder als Outer-HTML, vor dem bestehenden Inhalt, nach dem bestehenden Inhalt, gar nicht und so weiter. Allein diese wenigen Attribute machen HTMX bereits äußerst flexibel in der Anwendung.
Es wäre natürlich praktisch, während des Ladeprozesses einen Ladeindikator angezeigt zu bekommen. Tatsächlich ermöglicht HTMX, jedes beliebige Element als Ladeindikator zu definieren. Wünschen Sie sich eine Animation beim Einblenden des neuen Inhalts? Auch das ist mit HTMX kein Problem, da es entsprechende Animationen unterstützt. Soll die Kommunikation nicht über einen einmaligen HTTP-Request ablaufen, sondern periodisch, um beispielsweise Daten zu aktualisieren, also über Polling? Auch das ist mit HTMX machbar, indem Sie ein Zeitintervall festlegen. Bevorzugen Sie eine Push-Kommunikation? HTMX ermöglicht ebenfalls, WebSockets zu nutzen. Alternativ können Sie auf Server-Sent Events (SSE) zurückgreifen, die mit HTML5 eingeführt wurden. Und das ist nur ein Ausschnitt der Möglichkeiten. Für viele Standardanwendungen müssen Sie kein JavaScript mehr schreiben, sondern fügen lediglich ein paar Attribute in Ihr HTML ein, und HTMX erledigt den Rest im Hintergrund.
Übrigens, HTMX funktioniert dabei auch vollständig ohne npm. Es reicht aus, ein Script-Tag in Ihr HTML einzufügen und HTMX von einem Content Delivery Network (CDN) zu laden. Dabei beträgt die Größe lediglich etwa 14 KByte. Das System ist sogar mit dem Internet Explorer kompatibel, um nur einige Vorteile zu nennen. Es wird Ihnen also wirklich leicht gemacht, HTMX zu verwenden. Die Tatsache, dass sich HTMX einfach über ein CDN einbinden lässt, ist auch der Grund, warum ich zuvor erwähnte, dass die Download-Statistiken von npm mit Vorsicht zu betrachten sind. Denn diese spiegeln lediglich wider, wie oft HTMX über npm heruntergeladen wurde, nicht aber, wie oft es von einem CDN geladen oder möglicherweise direkt in Webseiten eingebettet wird – so wie es vor zehn Jahren üblich war. Daher ist es schwierig, die tatsächliche Verbreitung von HTMX zu ermitteln.
Allerdings dürfte die Verbreitung bei Weitem nicht so groß sein, wie die Menge an Fragen, die ich derzeit dazu erhalte, vermuten lässt. Es gibt einen gewissen Hype um HTMX, der aber eher kurz und überschaubar bleiben dürfte. Wie lange er anhalten und wie nachhaltig er sein wird, muss sich noch zeigen.
Wenn das Ergebnis eines HTTP-Requests direkt als Inner-HTML gerendert wird, wie verhält es sich dann mit APIs? Schließlich muss aus dem JSON, XML oder einem anderen Datenformat, das eine API liefert, etwas entstehen, das in HTML darstellbar ist. Es müsste also eine Art Templating oder Ähnliches geben, oder? Doch das ist nicht der vorgesehene Weg. Tatsächlich ist es so, dass der Server fertige HTML-Fragmente liefern muss. Zugegebenermaßen gibt es Plug-ins für HTMX, um unter anderem auch JSON verarbeiten zu können, allerdings macht die Dokumentation klar deutlich, welcher Stellenwert diesem Ansatz zugedacht wird – nämlich ein äußerst geringer.
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.
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.
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.
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.
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.
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? [5] 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) [6] auf. Vielleicht stellen wir gemeinsam fest, dass HTMX tatsächlich in Ihrem speziellen Fall sinnvoll ist.
URL dieses Artikels:
https://www.heise.de/-9633960
Links in diesem Artikel:
[1] https://www.heise.de/blog/Vanilla-Web-Der-Frontend-Trend-2024-9611002.html
[2] https://htmx.org/
[3] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[4] https://www.heise.de/hintergrund/Model-View-ViewModel-mit-Knockout-js-1928690.html
[5] https://www.heise.de/blog/Vanilla-Web-Der-Frontend-Trend-2024-9611002.html
[6] https://www.thenativeweb.io/
[7] mailto:map@ix.de
Copyright © 2024 Heise Medien
FreshRSS