Warum sich Gumroad nicht für htmx entschieden hat

 (htmx.org)
6 Punkte von GN⁺ 2024-10-04 | 1 Kommentare | Auf WhatsApp teilen
  • Gumroad prüfte für das neue Projekt Helper htmx in der Erwartung eines schlanken Frontends, wechselte jedoch mit steigenden Anforderungen an eine komplexe UX zu React/Next.js
  • Für einfache Interaktionen war htmx vielversprechend, doch bei Formularen mit dynamischer Validierung und bedingten Feldern wurde die serverseitige Logik langatmig und der Entwicklungsfluss unnatürlich
  • Der Drag-and-Drop-Workflow-Builder, Echtzeit-Kollaboration, komplexes State-Management und dynamische Formularerzeugung ließen sich im React-Ökosystem und mit dem Komponentenmodell direkter umsetzen
  • Materialien zur Problemlösung und die Unterstützung durch AI-Tools waren bei Next.js und React deutlich reichhaltiger; htmx war wegen mangelnder Open-Source-Trainingsdaten bei der Entwicklungsgeschwindigkeit im Nachteil
  • htmx kann für bestehende servergerenderte Apps oder einfache Interaktionsmodelle geeignet sein, aber für zustandsreiche Interfaces wie Helper passten React und Next.js besser

Hintergrund der Prüfung von htmx bei Helper

  • Gumroad prüfte beim Start des neuen Projekts Helper htmx als Frontend-Kandidaten
  • Die anfängliche Erwartung entstand aus früheren Erfahrungen, dass React schwerfälliger ist als nötig, und man sah in htmx eine Möglichkeit, einfache Interaktionen schlank hinzuzufügen
  • Im Team gab es auch die Einschätzung, htmx sei einem Meme ähnlich, das das komplex gewordene JavaScript-Ökosystem persifliert
    • So wie Tailwind wie eine andere Syntax für Inline-CSS wirkt, wurde auch htmx eher als eine andere Syntax für Inline-JavaScript gesehen
  • Tailwind hat sich in Gumroads Tooling etabliert, aber htmx ließ sich nicht passend für den Zweck von Helper erweitern und führte nicht zur bestmöglichen User Experience für die Kunden

Wo sich React/Next.js natürlicher anfühlte

  • Developer Experience und Formularverarbeitung

    • Eine korrekte Umsetzung wäre auch mit htmx möglich gewesen, aber Gumroad empfand den Weg, Funktionen in Next.js zum Laufen zu bringen, als intuitiver
    • Bei komplexen Formularen mit dynamischer Validierung und bedingten Feldern war die clientseitige Arbeit in React einfacher, während in htmx die serverseitige Logik länger wurde

  • UX- und Interaktionsgrenzen

    • htmx neigt dazu, Apps in eine Rails-/CRUD-Richtung zu drängen, wodurch die Standarderfahrung leicht gewöhnlich oder generisch wirkt
    • Das Drag-and-Drop-Interface des Workflow-Builders erforderte in htmx Umgehungslösungen und wirkte gröber als die geschmeidige Erfahrung mit React-Bibliotheken

  • AI-Tools und Geschwindigkeit bei der Problemlösung

    • AI-Tools sind mit Next.js vertrauter, mit htmx jedoch weniger, was auf fehlende Open-Source-Trainingsdaten zurückgeführt wurde
    • Für React/Next.js gibt es reichlich Material, sodass sich bei Problemen schneller Lösungen finden ließen

  • Komplexität und Skalierbarkeit

    • Je komplexer das Projekt wurde, desto mehr wurde die Einfachheit von htmx von einem Vorteil zu einer Einschränkung
    • Mit Echtzeit-Kollaboration und komplexen Datenvisualisierungen wurde das State-Management zwischen mehreren Komponenten im serverzentrierten Ansatz von htmx zunehmend schwieriger

Unterschiede nach Helper-Funktionen

  • Drag-and-Drop: react-beautiful-dnd aus dem React-Ökosystem bietet mit wenig Konfiguration flüssiges und barrierearmes Drag-and-Drop
  • Komplexes State-Management: Um Einstellungen und Bedingungslogik jeder Workflow-Stufe in Echtzeit in der UI abzubilden, waren React-Ansätze wie useState oder Redux direkter
  • Dynamische Formularerzeugung: Unterschiedliche Konfigurationsformulare je nach Schritttyp zu erstellen und sie anhand von Nutzereingaben zu verändern, ließ sich im React-Komponentenmodell intuitiver umsetzen
  • Echtzeit-Kollaboration: Die Funktion, bei der mehrere Nutzer gleichzeitig Workflows bearbeiten, ließ sich mit WebSockets und React vergleichsweise direkt umsetzen; in htmx wären komplexere serverseitige Logik und eigenes JavaScript nötig gewesen
  • Performance-Optimierung: Je größer und komplexer die Workflows wurden, desto feiner ließ sich das Rendering in React mit dem virtual DOM und Hooks wie useMemo und useCallback optimieren

Ökosystem und abschließende Einschätzung

  • Das React/Next.js-Ökosystem ist groß und ausgereift und bot für fast jedes Problem, auf das Gumroad stieß, eine Lösung
  • Mit htmx musste man häufiger Funktionen kompromissbehaftet umsetzen oder selbst neu bauen; auch bei der Integration von Drittanbieterdiensten und Bibliotheken gab es Fälle, in denen React-Bindings existierten, aber kein htmx-Gegenstück
  • Nach dem Wechsel zu React/Next.js bewertete Gumroad dies als die bessere Wahl für den Aufbau einer komplexen UX
    • Man konnte sich schneller bewegen, eine immersivere User Experience schaffen und vorhandene Tools und Bibliotheken nutzen
    • Auch die App-User-Experience für die Kernkundschaft von Helper ließ sich deutlich verbessern
  • Die Grenzen von htmx sind nicht unüberwindbar, aber der Lösungsweg führte weg von den Stärken von htmx hin zu Lösungen, die sich in einer JavaScript-zentrierten Umgebung natürlicher anfühlten
  • htmx kann für einfache Interaktionsmodelle oder Projekte, die auf bestehenden servergerenderten Apps aufbauen, eine gute Wahl sein
  • Für komplexe und zustandsreiche Interfaces wie Helper waren React und Next.js besser geeignet; Gumroad ist der Ansicht, den Tech-Stack auch künftig je nach Bedarf und neuen Technologien weiter neu zu bewerten

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-10-04
Meinungen auf Hacker News

  • Das hatte ich schon in einem anderen Thread geschrieben: Der Gumroad-CEO sagte auf Twitter, dass sie htmx in einem Projekt ausprobiert, sich am Ende aber für NextJS entschieden hätten.
    Ich war auf der Suche nach einem durchdachten negativen Erfahrungsbericht, der sich für die htmx-Website eignet, und fragte, ob er seine Erfahrung aufschreiben könne. Ich war dankbar, dass er sofort zustimmte.

    • Gerade weil das Projekt selbst offen zeigt, an welchen Stellen htmx nicht immer die beste Wahl sein kann, respektiere ich es noch mehr.
      Im Vergleich zu anderen Projekten, die behaupten, für alles die beste Lösung zu sein, ist das erfrischend.
      Besonders neugierig macht mich der Hinweis auf Drag-and-drop: Ist das in htmx wirklich schwierig, und falls ja, gibt es Pläne, das zu lösen?
    • Der Gumroad-CEO sagte außerdem, Rails selbst sei technische Schuld, und auf die Frage nach dem Grund antwortete er nur, React sei viel besser.
      Dabei ist es ja nicht so, dass man Rails und React nicht zusammen verwenden könnte.
      Der Text wirkt für mich weniger wie ein negativer Erfahrungsbericht zu htmx, sondern eher so, als sei die Entscheidung, htmx überhaupt zu erproben, womöglich von Anfang an falsch gewesen, sobald Drag-and-drop und Echtzeit-Zusammenarbeit ins Spiel kamen.
      Ich bin mir auch nicht sicher, was der Screenshot zeigen soll, aber trotzdem halte ich den Beitrag für gut geeignet für die htmx-Website.
    • Es ist respektabel, zu zeigen, wo htmx weniger geeignet sein kann als andere Werkzeuge.
      Für mich ist htmx weniger ein Ersatz für React als eher ein Ersatz für jQuery.
      htmx und jQuery fügen einem Dokument Interaktion hinzu; React will selbst das gesamte Dokument sein.
      Je nach Aufgabe sollte man unterschiedliche Werkzeuge wählen.
    • Nachdem ich den verlinkten Beitrag und https://htmx.org/essays/htmx-sucks/ gelesen habe, habe ich beschlossen, htmx weder zu verwenden noch anderen zu empfehlen.
    • Der andere Thread ist https://news.ycombinator.com/item?id=41727315.

  • Die Passage „KI und Tool-Unterstützung: Erwähnenswert ist auch, dass KI-Tools mit Next.js sehr vertraut sind, mit htmx aber deutlich weniger“ wurde zwar nüchtern als Nachteil formuliert, ist aber ein ziemlich unheimliches Vorzeichen für die Zukunft von Entwicklungstools, Libraries, Frameworks und Sprachen.
    Meine Prognose: Large Language Models werden bestehende Winner-takes-all- und First-mover-Effekte noch verstärken und durch mehr und bessere Trainingsdaten auch die Nutzung von Open-Source-Tools weiter begünstigen.

    • Das Thema KI- und Tool-Unterstützung ist im Grunde eine Fortsetzung des Problems von Community und Ökosystem.
      Schon vor Large Language Models hatte React den Vorteil, dass die meisten Fragen bereits auf StackOverflow beantwortet waren und es für fast jeden Einsatzzweck ausgereifte Libraries gab.
      Jetzt fragen manche Leute eben Large Language Models statt früher StackOverflow, aber das Ergebnis ist dasselbe.
      Es bringt Vorteile, das zu verwenden, was viele andere auch verwenden.
    • Dass Large Language Models Winner-takes-all- und First-mover-Effekte bei Entwicklungstools verstärken, dürfte für Menschen stimmen, die sich beim Programmieren auf Large Language Models verlassen.
      Als langfristige Strategie für eine Karriere als Software Engineer halte ich das allerdings entschieden für keine besonders gute Wette.
    • KI-Tools sind auf einen bestimmten Zeitpunkt eingefroren, und selbst wenn man sie mit neuem Material trainiert, ist die Menge an Informationen, die sie lernen können, begrenzt.
      Ich habe überlegt, ob das vielleicht sogar etwas Gutes sein könnte.
      Die Softwarebranche verbringt zu viel Zeit damit, den neuesten Tools, Sprachfeatures und Frameworks hinterherzulaufen.
      Ein wenig Stagnation könnte positiv sein, wenn sie dazu führt, dass man mit den vorhandenen Werkzeugen Arbeit erledigt, statt alle sechs Monate einen neuen Hammer zu bauen.
    • Wenn ein Entwickler ohne etwas, das den Code für ihn schreibt, nicht arbeiten kann, weiß ich nicht, warum man ihn überhaupt einstellen sollte.
    • Über diesen Punkt mache ich mir keine großen Sorgen, und Gumroads Bedenken könnten übertrieben sein.
      Allein aus dem Kommentar ist nicht ersichtlich, ob die tatsächliche Erfahrung war, dass KI schlecht mit HTMX umgehen konnte, oder ob es eher allgemein um mangelnde Materialien ging.
      Large Language Models funktionieren oft sehr gut wie ein universeller Übersetzer.
      Wenn sie allgemeine Muster und Konzepte populärer Frameworks gelernt haben und die Syntax kleinerer Frameworks einigermaßen kennen, erzeugen sie meiner Erfahrung nach auch ziemlich guten Code für Nischen-Frameworks.
      Das ist ähnlich wie bei Piraten, die auch über Themen in Piratensprache sprechen können, über die in den Trainingsdaten nie ein Pirat gesprochen hat.

  • Bei der Passage „Beim Erstellen komplexer Formulare mit dynamischer Validierung und bedingten Feldern mussten wir komplexe serverseitige Logik schreiben, um Dinge zu erledigen, die in React einfache clientseitige Arbeit wären“ musste ich an das Anakin-Padme-Meme denken.
    „Aber ihr implementiert doch trotzdem auch serverseitige Validierung … oder?“

    • Wenn ein Webformular komplizierter ist als ein Papierformular, sollte man vielleicht das Webformular selbst überdenken.
      Formulare, die in React einfach, in htmx aber schwierig sind, fallen mir kaum ein – außer wenn man globalen Anwendungszustand im React-Stil hineinstecken und 90 % mit einer Library erledigen möchte.
    • Validierung gibt es auch auf dem Server.
      Allerdings einmal beim Absenden, nicht auf jeder Seite.

  • Im Gegensatz zur Aussage „Wir dachten, htmx könnte eine gute Lösung sein, um das Frontend sehr schlank zu halten“ wirkt es so, als sei htmx unpassend geworden, sobald man das schlanke Frontend aufgegeben hatte.
    Man begann, Third-Party-Libraries zu verwenden, um komplexe UI/UX und State Management zu rendern.
    Außerdem ist es kein fairer Vergleich, zu sagen „In React war X einfacher“, wenn man es dort mit einer Third-Party-Library erledigt hat.
    Man musste es nur deshalb nicht selbst machen, weil jemand anderes es schon gemacht hatte.
    Ich stimme dem Beitrag in vielem zu, aber wenn klar war, dass komplexer Zustand und Rendering nötig sind, war htmx von Anfang an keine gute Lösung.

    • Genau so sehe ich es auch.
      Ich mag htmx, aber dieser Beitrag zeigt, dass dem Autor offenbar einiges an technischem Verständnis fehlte.
      Das wirkt weniger wie eine Abwägung von Vor- und Nachteilen, die schon mit ein wenig Kenntnis der Webplattform und der Dokumentation auf htmx.org sichtbar gewesen wären, sondern eher so, als habe man HTMX ausprobieren wollen, weil die Stimmung gerade danach war.
    • Das bildet eine schöne Symmetrie zu Beiträgen von Leuten, die React ursprünglich gar nicht hätten verwenden sollen und dann schreiben: „Wir haben unsere React-App auf htmx umgestellt, und alles wurde viel besser.“
    • Die Gegenüberstellung htmx versus JavaScript erinnert mich an Tests mit Behavior-driven Development in behave im Vergleich zu pytest-Tests.
      Die Gherkin-Sprache sieht in einfachen Fällen gut aus und lässt sich prinzipiell auch auf komplexere Fälle ausweiten, aber je mehr Abstraktionsebenen man verwalten muss, desto angenehmer wird das rein Python-basierte pytest.
    • Ich dachte genau dasselbe.
      Der Projektumfang war überhaupt nicht „einfach“, und in meinem Fall wäre ich direkt zu React gegangen.
    • Schon die Beschreibung der gewünschten Features ließ erkennen, dass schwergewichtiges JavaScript unvermeidlich nötig sein würde.

  • Zu der Stelle, dass „die Implementierung eines Drag-and-drop-Interface für den Workflow-Builder in htmx eine große Herausforderung war und im Vergleich zu der reibungslosen Erfahrung, die man mit einer React-Bibliothek bekommt, umständliche Workarounds erforderte“: HTMX ist am besten, wenn das Frontend-Bundle nur so viel macht wie nötig und nicht mehr.
    Man kann sich an das Event htmx.onLoad hängen und dann im geladenen Content Markup mit entsprechenden Attributen finden und anbinden, etwa columns, cards, tasks usw.
    Zum Beispiel kann man sortable.js an das gerenderte Markup binden und die sortable-Events mit Status-Updates über HTMX verknüpfen.
    Das ist ziemlich einfach, und in der Dokumentation gibt es genau so ein Beispiel: https://htmx.org/docs/#3rd-party

    • Ich verwende HTMX zusammen mit UIKit-Komponenten.
      Moderne, zustandsbehaftete und dynamische Websites sind keineswegs unvereinbar mit HTMX.

  • Wenn man den Artikel liest, wirkt das Team eher mit Frontend-Entwicklung vertraut als mit Backend-Entwicklung.
    Aus Sicht eines Entwicklers alter Schule sieht man manchmal ein wenig Angst und Missverständnisse in der Denkweise von Frontend-Entwicklern.
    Ehrlich gesagt denke ich, dass man nur seine Denkweise ein klein wenig anpassen muss, um zu verstehen, wie dieser Ansatz funktioniert; ich verstehe aber auch, dass viele Menschen in ihrer gesamten Laufbahn nie einen klassischen Client/Server-Ansatz gesehen haben.
    Trotzdem kann man den Wert fertiger React-Komponenten sowie den Vorteil leicht auffindbarer Dokumentation und Hilfe nicht ignorieren.

    • Ich denke, nicht nur Entwickler, sondern auch UX-Designer, die in React denken, sind eines der größten Hindernisse für die Einführung von htmx.
      Eine ganze Generation von Designern hat Mobile und Web sehr ähnlich gestaltet und die Komplexität der Umsetzung den Entwicklern zugeschoben.
      Aber das Web sollte, wenn möglich, anders sein als Mobile, und es darf auch anders sein.
      Im Artikel heißt es, das Design sei zu „generic“ gewesen, wie bei einer CRUD-App, aber ist das wirklich schlecht?
      Wir haben die großartige Errungenschaft eines allgemein akzeptierten Dokumentmodells, das über alle Sites hinweg eine vorhersehbare User Experience ermöglicht, und sehen darin nur „langweilig“.
      Als wäre Langeweile an sich etwas grundsätzlich Problematisches.
      Ich verstehe den Marktdruck, einzigartige, gebrandete Erlebnisse zu verlangen, die sich wie mobile Apps anfühlen, aber ich frage mich, wie es wäre, wenn Designer neben dem Denken im React-Stil auch im WWW-Stil denken könnten.

  • Ich finde es gut, dass HTMX diesen und ähnliche Artikel auf der eigenen Site veröffentlicht.
    Es scheint einige stichhaltige Gründe gegeben zu haben, warum HTMX allein nicht gut passte.
    Ich bin kein Frontend-Experte, habe aber ein paar Gedanken dazu.
    Erstens: Muss man Formularvalidierung nicht ohnehin auch im Backend machen?
    Ich frage mich, warum es so schwierig war, dass das Backend-System die Ergebnisse an das Frontend weitergibt.
    In vielen Fällen gibt es gute Gründe, Formularvalidierung sowohl im Frontend als auch im Backend durchzuführen; dann reicht HTMX allein natürlich nicht aus, aber die Formulierung dieses Problems wirkt etwas verwirrend.
    Zweitens kann eine App, wenn man nur HTMX verwendet, in gewissem Maß in diese Richtung gedrängt werden, was in manchen Fällen gut ist; sie scheinen aber entschieden zu haben, dass sie für ihre Kunden einen anderen Ansatz brauchen.
    Drittens würde ich gern mehr darüber wissen, wie dieses Team AI-Tools eingesetzt hat, wenn die Abhängigkeit von AI-Tools zu einem zentralen Problem werden konnte.
    Wenn AI-Entwicklungswerkzeuge künftig wichtiger werden, ist es auch eine interessante Frage, ob die Hürde dafür, für neue Frameworks oder Programmiersprachen genügend Tools und Integrationen zu bekommen, zu hoch wird.
    Viertens verlangen manche Projekte, wie es eine häufige Beschwerde über HTMX ist, mehr als das, was HTMX bietet.
    Fünftens ist einer der Gründe, warum ich Django und Python mag, ebenfalls die tiefe Community sowie das Ökosystem aus Integrationen und Add-ons.
    Etwas wie https://unpoly.com/, das konzeptionell ähnlich ist, aber mehr Funktionen als HTMX bietet, hätte für sie vielleicht besser gepasst.

  • Zu der Aussage „der Entwicklungsprozess von Next.js fühlte sich natürlich an“: Ich weiß nicht, welcher Teil dieser ReactJS-Syntax natürlich sein soll.
    Sie mag vertraut sein, aber natürlich ist sie nicht.
    useEffect(() => { const timer = setInterval(() => { setCount((prevCount) => prevCount + 1); }, 1000); return () => clearInterval(timer); }, []);

    • Soweit ich weiß, hat HTMX keine elegante Lösung für Timer und Intervalle.
      Am Ende muss man das wohl unbeholfen mit JavaScript verdrahten.
    • Dieses Codebeispiel ist ziemlich großzügig.
      Wenn man einen Custom Hook mit variablem Timeout will, kann es deutlich komplexer werden.
      Auch Dan musste zu diesem Thema einen langen Artikel schreiben: https://overreacted.io/making-setinterval-declarative-with-r...
    • Ich frage mich, wie Code aussehen würde, der in diesem Anwendungsfall natürlich wirkt.
      Kannst du welchen schreiben?

  • Es ist lobenswert, dass htmx.org diesen Artikel hostet.

    • Ich finde es wirklich wertvoll, wenn ein Service oder Tool nicht nur erklärt, warum man es verwenden sollte, sondern auch warum man es nicht verwenden sollte.
    • Einen solchen Artikel zu veröffentlichen, ist wirklich eine demütige und ehrliche Haltung.
      Wenn nun jemand htmx ausprobiert und wütend wird, weil es die eigenen Anforderungen nicht erfüllt, gibt es am Ende wenigstens Material, auf das man verweisen kann.
    • Er ist unter „On The Other Hand…“ auf https://htmx.org/essays/ verlinkt.
    • Anfangs hatte ich eine kleine rantartige oder sarkastische Abrechnung erwartet, aber tatsächlich war es ein guter Artikel mit guten Punkten, was mich gefreut hat.
      Ich verwende htmx in einigen meiner Projekte und fand es ziemlich gut.
      Solche Artikel bestärken mich eher darin, htmx zu nutzen, weil sie selten zeigen, wo htmx gut ist und wo es Schwächen hat.

  • Der dritte Punkt wirkt beängstigend.
    Ich stelle mir eine Welt vor, in der Unternehmen dafür bezahlen, dass ihr Framework in den Trainingsdatensätzen der Modelle überrepräsentiert ist, und auf dieser Grundlage Verträge verkaufen.
    Das ist so ähnlich, als wäre Suchmaschinenoptimierung fest in Entwicklungstools eingebaut.