Eine gemäßigte Kritik an Htmx

• Die grundlegende und einfache Idee von Htmx gefällt mir wirklich sehr, aber nachdem wir es im ganzen Team verwendet haben, wurde klar, dass es in der Praxis nicht einfach ist, sondern ziemlich komplex.

Die Vererbung von Htmx-Attributen ist eindeutig ein Fehler

• In Code-Snippets ist die Attributvererbung implizit und überraschend.
• Wie in CSS ist Vererbung ein billiger Hack, hat aber ihren Preis.
• Sie widerspricht der Behauptung des Autors zur Lokalität des Verhaltens.
• Bei mehreren Attributen ist die Standardvererbung unterschiedlich (z. B. wird hx-delete nicht vererbt, hx-confirm und hx-ext jedoch schon).
• Man muss sich Ausnahmen merken und am Ende alles explizit ausdrücken, wodurch die Vererbung sinnlos wird.

Die meisten interessanten Web-Apps können DOM-Elemente nicht vollständig ersetzen

• DOM-Elemente haben fast immer browserlokalen Zustand (z. B. den Offen/Geschlossen-Status eines <details>-Elements, den Eingabewert eines <input>-Elements oder den Offen/Geschlossen-Status eines Dropdown-Elements).
• Wenn Htmx den einfachen Ansatz verwendet, outerHTML direkt zu ersetzen, geht dieser Zustand vollständig verloren.
• Auch die Morphdom-Erweiterung überschreibt einige Elemente anders als erwartet.

Zustand direkt im DOM-Element zu speichern, ist eine schlechte Idee

• Morphdom soll die Probleme aus dem vorherigen Abschnitt lösen, aber es zeigt sich, dass die Funktionsweise von Htmx darauf basiert, Elemente vollständig zu ersetzen.
• Die Request-Queue wird direkt im DOM-Element selbst gespeichert.
• Wenn eine Anfrage gestartet wird, hat dieses Element oder ein anderes, das darauf verweist, die Request-Queue.
• Wenn man ein DOM-Element vollständig ersetzt, wird die Queue zurückgesetzt, wodurch einige schlechte Fehlermodi vermieden werden können.
• Bei Morphdom bleibt das Element jedoch erhalten, also bleibt auch die Queue erhalten.
• Man landet damit in einer Art undefiniertem Verhaltensbereich, in dem das Design von Htmx verletzt wird.

Der Standard-Queueing-Modus ist chaotisch

• Standardmäßig bricht Htmx eine laufende Anfrage ab, wenn aus derselben Queue (demselben Element) eine weitere Anfrage ausgelöst wird.
• Das ist die Standardstrategie.
• Diese Tatsache wurde erst später entdeckt.
• Das ist sehr unintuitiv und bedeutet, dass Arbeit verloren geht.

Event-Trigger sind nicht lokal

• Event-Trigger helfen oft dabei, etwas auszulösen, sind aber ein nichtlokaler Effekt und haben ähnliche Probleme wie die Attributvererbung.
• Wenn man in einer serverseitigen Sprache DSL-Arbeit macht, kann das teilweise helfen, aber es fühlt sich ähnlich an wie callback-basierte JavaScript-Programmierung alter Schule.
• Wenn ein Event eintritt, „abonniert“ man es und führt etwas aus.

Komponentenstatus lässt sich nicht gut erhalten

• Ein breiteres Problem, das dem Zustand von DOM-Elementen ähnelt, ist, dass auch eigene Komponenten ihren eigenen Zustand haben.
  • Wenn man zum Beispiel eine Seite mit drei Bereichen haben möchte, die jeweils eigenen serverseitig benötigten Zustand besitzen (z. B. die Seite einer Ergebnismenge) sowie Zustand, den React oder WebComponents benötigen, entsteht ein Problem bei der Synchronisierung des Zustands zwischen Eltern- und Kindkomponenten.
• Htmx bietet dafür keinen guten Ansatz.
  • Es gibt Ideen wie Query-Parameter, versteckte Formulareingaben, Event-Trigger usw., aber alle haben große Einschränkungen.
• React und Halogen haben darauf Antworten.
  • In beiden Fällen haben Kindkomponenten ihren eigenen Zustand, und Eltern können „props“ wie etwa „Ratschläge“ bereitstellen.
  • Zusätzlich haben sie internen eigenen Zustand, den sie gegenüber Props ignorieren oder priorisieren können.
  • Props werden typischerweise vom Server bereitgestellt oder vom Server abgeleitet, während Zustand typischerweise clientseitiger Zustand ist.
• Fertige Komponenten, die mit React geliefert werden oder verwendet werden müssen, setzen oft React voraus.
  • React und Htmx arbeiten nicht gut zusammen.
  • Es wurde mit WebComponents gearbeitet, aber damit gab es keine zufriedenstellenden Ergebnisse; zudem haben sie überraschend merkwürdige Einschränkungen.
  • Es wurden auch direkte Brücken zu React-Komponenten gebaut, die in serverseitigen Sprachen verwendet werden, aber im Allgemeinen kämpfen Htmx und React um den Zustandsfluss und die Verwaltung von DOM-Elementen.
  • Alpine wurde ebenfalls ausprobiert; es ist gut, aber wiederum eine weitere clientseitige Programmierbibliothek und damit redundant, wenn React bereits im Codebestand vorhanden ist.

Trotzdem gibt es Vorteile

• Eine serverseitige Sprache verwenden zu können, ist ein enorm offensichtlicher und unstrittiger Vorteil.
• Niemand im Team würde all diese Business-Logik in TypeScript neu schreiben wollen.
• Es ist keine Serialisierung von DB-Typen in Frontend-Typen nötig.
  • Es gibt kein Datenleck und kein Bedarf an GraphQL.
• Man kann die stärkeren Abstraktionsmöglichkeiten serverseitiger Sprachen nutzen.
• Statt dieselbe Validierung sowohl im Frontend als auch im Backend zu implementieren, kann man Form-Builder der serverseitigen Sprache verwenden.
• Dennoch sind auch die oben genannten Nachteile real.

Htmx-in-React?

• Eine attraktive zukünftige Richtung könnte sein, Htmx in React neu zu implementieren.
  • Der Server würde JSON-Blobs senden, die React in Virtual-DOM-Komponenten umwandelt.
  • Damit ließe sich das Problem des Komponentenstatus lösen.
  • Es wäre keine spezielle Brücke mehr nötig, um React-Komponenten zu verwenden.
  • Man könnte React-gebundene Web-Fetching-Bibliotheken verwenden und dabei eine bestimmte Queueing-Entscheidung von Htmx gezielt vermeiden.
  • Auch die Morphdom-Probleme und die Probleme mit Browser-DOM-Eingabeelementen würden gelöst, da diese in React weitgehend als gelöste Probleme gelten.
• Auf diese Weise könnte man die Htmx-Abhängigkeit entfernen und gleichzeitig die Vorteile der Idee behalten — vorausgesetzt, es gibt das Budget, um ein so großes Vorhaben zu starten.

Meinung von GN⁺

• Die Grundidee von Htmx ist attraktiv, aber in der Praxis können bei der Nutzung mehrere komplexe Probleme auftreten.
• Einige Designentscheidungen von Htmx — etwa Attributvererbung, das Ersetzen von DOM-Elementen und Queueing-Modi — sind nicht intuitiv und können unerwartetes Verhalten verursachen.
• Auch die Integration mit React oder WebComponents scheint nicht einfach zu sein.
• Dennoch ist die Möglichkeit, serverseitige Sprachen zu verwenden, ein großer Vorteil.
• Eine künftige Neuimplementierung von Htmx auf Basis von React könnte ebenfalls eine interessante Richtung sein.

[felizgeek]

Interesse ist besser als Gleichgültigkeit~ Ich mag HTMX. Auch die Philosophie dahinter.
Es fühlt sich auch SQLite sehr ähnlich an, haha

[savvykang]

Worin ähneln sich SQLite und HTMX?

[aer0700]

Ähnlich wie Sqlite?

[halfenif]

Der Kommentar ist tiefgründig. Philosophie ...

[savvykang]

Wenn Sie vor dem Aufkommen von SPAs bereits Erfahrung mit Webentwicklung auf Basis von serverseitigem Rendering und jQuery gesammelt haben, werden Sie sofort verstehen, dass es sich um eine Technologie aus genau dieser Richtung handelt. Vermutlich unterliegen diejenigen, die mit SPA in die Webentwicklung eingestiegen sind und auf der Suche nach etwas Neuem waren, einem Missverständnis.

[heycalmdown]

Ich glaube allerdings nicht, dass dieser Artikel in Korea geschrieben wurde.

[ndrgrd]

Stimmt. Es wirkt wie ein Tool, das für einfache Seiten gemacht ist, und ich verstehe nicht, warum Diskussionen darüber entstehen, dass man irgendwelche seltsamen Beispiele oder Use Cases heranzieht und dann sagt, es sei dafür nicht geeignet.

[roxie]

Wie man auf der Startseite von htmx sehen kann, vertritt htmx eine Haltung, die nahelegt, dass moderne Frontend-Technologien einschließlich React (wenn es nach ihnen ginge) nicht nötig sind.

[rlrsbtm80879]

Das hängt mit dem Grund zusammen, warum htmx Aufmerksamkeit bekommt. Auch dieser Artikel ist eine Übersetzung eines ausländischen Gastbeitrags, und im Ausland sind viele der ganzen State-Management-Themen von React leid. Deshalb wurde htmx, das ähnliche Funktionen wie React bietet, aber im Gegensatz zu React kein State Management braucht, als Alternative zu React betrachtet. Darum wird htmx immer wieder mit React verglichen.

[ndrgrd]

Tja. Wenn das der Grund ist, wäre es dann nicht richtig, zum Vergleich etwas heranzuziehen, das behauptet, React ersetzen zu können?

Schon wenn man sich nur die auf dieser Seite aufgelisteten Eigenschaften ansieht, ist HTMX nichts, das auf komplexen Seiten zum Einsatz kommen sollte, und überhaupt nichts, das React ersetzen könnte.

[GN⁺]

Hacker-News-Kommentare

• Die Meinungen zur Attributvererbung gehen auseinander. Sie kann mit der Option htmx.config.disableInheritance deaktiviert werden

  • Client-seitiger Zustand und htmx-Swaps passen nicht immer gut zusammen, besonders in einfachen Fällen
  • Events sind mächtig, aber komplex und schwer zu debuggen. Das ist eine Eigenschaft ereignisgesteuerter Programmierung
  • Keine Zustimmung zum Standard-Wartemodus. Statt bestehende Anfragen abzubrechen und zu ersetzen, wird die aktuelle Anfrage beibehalten und nur eine zusätzliche Anfrage in die Warteschlange gestellt
  • Werbung für eine Tasse für Leute, die htmx nicht mögen

• Der Grund, nicht ins Frontend eingestiegen zu sein, sind die vielen Optionen, die viele Kritik und die häufig wechselnden Techniktrends

  • Auch bei Backend- und Systemprogrammierung gibt es Meinungsverschiedenheiten, aber es ist weniger chaotisch als im Frontend

• Es wird mit HTMX ein performanter Storefront aufgebaut, und das Ergebnis ist zufriedenstellend

  • Ein großer brasilianischer Bekleidungshändler nutzt HTMX und eine Strategie mit partiellem Rendering

• Die Idee „HTMX in React“ kommt einer Neuerfindung von React Server Components gleich

  • Der Server sendet JSON, das React in Virtual-DOM-Komponenten umwandelt
  • Damit lassen sich Probleme mit Komponentenstatus lösen, und React-Komponenten können ohne spezielle Bridge verwendet werden
  • Mit React verbundene Web-Fetching-Bibliotheken können genutzt und die Warteauswahl von HTMX vermieden werden
  • Probleme mit morphdom und DOM-Input-Elementen im Browser lassen sich lösen
  • RSC ist noch experimentell, und die Standardimplementierung geht davon aus, dass JS auf dem Server ausgeführt wird

• Keine Zustimmung zur Meinung, dass der Standard-Wartemodus unvernünftig sei

  • Wenn ein Nutzer Eingaben absendet, sie zwischendurch ändert und erneut absendet, sollte die Anfrage abgebrochen werden
  • Wenn eine Antwort Inhalte durch andere IDs ersetzt, kann die zweite Antwort nicht auf dieselbe Weise ersetzen

• Beim ersten Einsatz von HTMX ließ es sich für einfache Aufgaben leicht anwenden und machte Spaß

  • Ob es in komplexen Projekten eingesetzt würde, ist noch unklar

• Nach dem Lesen der Beschwerden über Zustand entsteht der Eindruck, dass der Autor vor React noch nie Websites gebaut hat

  • Das Beispiel ist nicht nachvollziehbar, und es wirkt, als habe er versucht, htmx wie React zu verwenden, und sei enttäuscht gewesen, weil es nicht den Erwartungen entsprach

• Es wird gefragt, ob HTMX eine Funktion wie Turbo Mount hat

  • Das wird für eine der besten Arten gehalten, Hotwire/Turbo zu nutzen

• Es besteht Interesse, mehr über das Problem zu erfahren, dass morphdom unerwartet einige Elemente überschreibt

  • Das Bewahren des Zustands von Eingabe- und Detail-Elementen ist eine Kernfunktion von Bibliotheken wie morphdom