Why Gumroad Didn't Choose Htmx

Original Article ↗ Hacker News Discussion ↗

Reaction to HTMX Hosting the Critique

  • Many praise HTMX for prominently hosting a thoughtful negative case study and linking to other “when not to use it” essays.
  • Compared to typical marketing, this honesty is seen as a credibility boost and reminiscent of SQLite/Tor “limitations” pages.
  • A few readers say the essays (including “htmx sucks”) convinced them not to use HTMX, which the project seems comfortable with.

Where HTMX Fits Well vs Poorly

  • Consensus: HTMX shines for server-rendered, CRUD‑style apps, admin tools, and “keeping everything in your head.”
  • It works well when the server is the single source of truth and interactions are mostly request/response with incremental updates.
  • It struggles when the UI requires rich client-side state: complex drag‑and‑drop builders, multi‑state workflows, real‑time collaboration, highly dynamic forms.

Drag‑and‑Drop and Complex UX

  • Some argue the Gumroad use case (complex workflow builder, real‑time features) was a poor fit for HTMX from the outset.
  • Others note drag‑and‑drop is feasible by combining HTMX with libraries like Sortable.js and custom JS, but acknowledge this “glue code” is less integrated than React’s ecosystem.
  • Point made that HTMX makes it harder to “quickly add a fat frontend” compared to React’s off‑the‑shelf components.

Validation, Forms, and State

  • Debate over the article’s complaint about complex validation: several insist robust apps must validate on the server regardless of front‑end stack.
  • Some say complex, conditional forms are exactly where SPA patterns shine; others maintain HTMX can handle them if you accept server‑driven state and round‑trips.

Ecosystem, Community, and AI Support

  • Strong agreement that React/Next’s component ecosystem, job market, docs, and StackOverflow answers are major advantages.
  • AI support is framed as a new selection pressure: LLMs are much better at mainstream stacks and often hallucinate with HTMX or Elixir/Phoenix.
  • Some see this as entrenching existing tools; others argue good engineers should not rely heavily on LLMs, though many now treat AI as a key productivity aid.

Docs, Learning Curve, and Hybrid Approaches

  • Several note HTMX plus light client libraries (Alpine, web components, even React islands) is a common and underappreciated pattern.
  • One detailed critique says HTMX docs feel conceptually simple but hide subtle request/response and attribute pitfalls; more examples and validation tooling are requested.
  • Broader theme: there is no one‑size‑fits‑all; HTMX is closer to “HTML/jQuery on steroids” than a full React replacement, and teams should match tools to UX and team skills.