Warum Gumroad sich nicht für htmx entschieden hat

• Gumroad erwog bei dem Start des neuen Projekts Helper den Einsatz von htmx.
• Um die Komplexität von React zu vermeiden, wollte man htmx verwenden, doch im Team gingen die Meinungen auseinander.
• Anfangs schien htmx vielversprechend, um einfache Interaktionen hinzuzufügen.

Grenzen von htmx

• Intuitivität und Developer Experience: Mit htmx zu arbeiten war weniger intuitiv als mit Next.js. Bei der Umsetzung komplexer Formulare und dynamischer Validierung wurde die serverseitige Logik komplizierter.
• UX-Einschränkungen: htmx verfolgt grundsätzlich einen Rails/CRUD-Ansatz, wodurch die User Experience eintöniger wurde. Eine Drag-and-Drop-Oberfläche war damit schwieriger umzusetzen als mit React.
• AI- und Tool-Support: Next.js ist mit AI-Tools gut kompatibel, htmx dagegen nicht. Das wirkte sich auf Entwicklungsgeschwindigkeit und Problemlösung aus.
• Skalierungsprobleme: Als das Projekt komplexer wurde, konnte htmx die Anforderungen nicht mehr mittragen. Beim Hinzufügen von Echtzeit-Kollaboration und komplexer Datenvisualisierung wurde State Management schwierig.
• Community und Ökosystem: Das React/Next.js-Ökosystem ist ausgereift und bietet vielfältige Lösungen, htmx dagegen nicht.

Die endgültige Entscheidung: Wechsel zu React/Next.js

• React/Next.js erwies sich als besser geeignet für den Aufbau komplexer UX.
• Vorteile von React kamen bei Drag-and-Drop-Funktionen, komplexem State Management, dynamischer Formularerstellung, Echtzeit-Kollaboration und Performance-Optimierung zum Tragen.
• Um die Grenzen von htmx zu überwinden, wechselte das Team zu React; das unterstützt die langfristige Vision des Projekts.
• Mit dieser Entscheidung ist man zufrieden: Derzeit kann das Team schneller vorankommen, eine ansprechendere User Experience schaffen und bestehende Tools sowie Bibliotheken nutzen.

Erkenntnisse aus der Erfahrung

• Es ist wichtig, leichte Alternativen in Betracht zu ziehen, aber ebenso wichtig ist es, eine Technologie zu wählen, die mit dem Projekt mitwachsen und die langfristige Vision unterstützen kann.
• Im Fall von Helper erwiesen sich React und Next.js als genau diese Wahl, und nach dem Wechsel konnte die User Experience der App für die Kernkunden deutlich verbessert werden.

Zusammenfassung von GN⁺

• Die Erfahrung von Gumroad zeigt, dass es wichtig ist, leichte Alternativen zu prüfen, aber ebenso wichtig, Technologien zu wählen, die das Wachstum des Projekts und seine langfristige Vision unterstützen können.
• htmx kann für einfache Interaktionsmodelle oder bestehende serverseitig gerenderte Anwendungen gut geeignet sein.
• Für die komplexe zustandsbasierte Oberfläche von Helper waren React und Next.js die bessere Wahl.
• Der Technology Stack kann je nach Bedarf neu bewertet werden, und es ist wichtig, flexibel zu bleiben, wenn neue Technologien auftauchen.

[GN⁺]

Hacker-News-Kommentare

• Der CEO von Gumroad teilte seine Erfahrung, htmx ausprobiert und dann zu NextJS gewechselt zu sein. Das war nützliche Information für jemanden, der nach negativen Erfahrungen mit htmx suchte

  • AI-Tools sind mit Next.js vertraut, aber nicht mit htmx. Das liefert eine wichtige Prognose für die Zukunft von Entwickler-Tools
  • Es gibt die Prognose, dass LLMs die bestehende Winner-takes-all-Struktur verstärken und die Nutzung von Open-Source-Tools fördern werden

• Beim Erstellen komplexer Formulare wurde die serverseitige Logik kompliziert und schwieriger als die clientseitige Arbeit in React

  • Es gibt ein Meme, das betont, dass Validierung auch auf der Serverseite implementiert werden muss

• Man wollte das Frontend mit htmx schlank halten, nutzte dann aber Drittanbieter-Bibliotheken für komplexe UI/UX und State-Management

  • Es gibt die Meinung, dass die Arbeit in React nur deshalb einfacher war, weil Drittanbieter-Bibliotheken verwendet wurden
  • Wenn komplexer State und Rendering verwaltet werden müssen, wäre htmx von Anfang an wohl keine gute Wahl gewesen

• Mit htmx war es schwierig, ein Drag-and-Drop-Interface umzusetzen, und mit React-Bibliotheken ließ sich eine flüssigere Erfahrung erzielen

  • Bei htmx ist es gut, nur so viel Frontend-Bundle zu verwenden wie nötig
  • Mit dem Event htmx.onLoad kann man das geladene Content nach Markup mit Attributen durchsuchen und es verbinden

• Das Team scheint mit Frontend-Entwicklung vertrauter zu sein und hatte Schwierigkeiten bei der Kommunikation mit dem Backend

  • Die Vorteile von React-Komponenten sowie die leichte Auffindbarkeit von Dokumentation und Hilfen werden anerkannt

• Es gibt die Meinung, dass sich der Entwicklungsprozess mit Next.js natürlicher anfühlte

  • Es gibt auch die Meinung, dass die ReactJS-Syntax sich nicht natürlich anfühlt

• Es ist interessant, dass HTMX diese Erfahrung teilt, und es gibt die Meinung, dass es Projekte gibt, für die HTMX allein nicht ausreicht

  • Es wird betont, dass Formularvalidierung auch im Backend notwendig ist
  • Der Fall eines Teams mit hoher Abhängigkeit von AI-Tools ist interessant
  • Es gibt die Meinung, dass Plugins nötig sind, um die Grenzen von HTMX auszugleichen

• Es gibt Lob dafür, dass HTMX.org solche Essays hostet

• Es gibt die Sorge, dass AI-Tools die Einführung neuer Frameworks oder Programmiersprachen erschweren könnten

  • Man stellt sich vor, dass sie Entwickler-Tools ähnlich wie SEO beeinflussen könnten