Building a single-page app with Htmx

Original Article ↗ Hacker News Discussion ↗

Developers weigh the trade-offs of using htmx to build single-page–app‑like experiences versus sticking to traditional server‑rendered pages or full SPA frameworks like React and Vue. Many find htmx ideal for progressively enhancing MPAs with small “islands” of interactivity, especially when they prefer to keep most state and logic on the backend, but report that complexity grows quickly for richer, highly reactive UIs. The overall sentiment is that htmx is a strong fit for simple to moderately interactive apps and backend-centric workflows, while large, stateful frontends still benefit from dedicated SPA frameworks.

Scope and intent of using HTMX

  • Many see HTMX as ideal for enriching server-rendered MPAs: forms, CRUD, dashboards, small internal tools, and hobby projects.
  • It’s praised for letting backend‑oriented developers stay mostly in their server language and HTML, avoiding heavy JS frameworks and build steps.
  • Several people explicitly say HTMX is not a good fit for large, highly interactive SPAs (e.g., “next Facebook”), but fine for simpler apps or “next Amazon”-class backoffice tools.

HTMX for SPAs and complexity concerns

  • A major critique: building a full SPA with HTMX leads to:
    • Re‑rendering large HTML fragments and losing local UI state.
    • Manually wiring every place that needs updating when state changes.
    • Gradual reinvention of components and a mini‑framework on top of HTMX.
  • Some note that HTMX offers tools to mitigate this (morph swaps, hx-swap-oob, hx-preserve, websockets/SSE), but critics argue this stays imperative and scales poorly compared to declarative frameworks.
  • Multiple commenters report hitting a “complexity wall” once requirements get more dynamic or stateful.

Islands of interactivity and tool combinations

  • Common pattern: traditional SSR + HTMX “islands,” optionally combined with:
    • Alpine.js for client‑side state and micro‑interactions.
    • Astro or similar “islands architecture” frameworks.
    • Occasional embedded React/Svelte apps for particularly complex widgets.
  • Some libraries/frameworks are mentioned that add component concepts on the server side (e.g., with Django, Go, Python).

State location: server vs client

  • Pro‑HTMX side: keep most state on the server; HTML over the wire keeps UI and persisted state in sync, avoiding “lying UIs.”
  • Critics: pushing every interaction to the server increases latency, hurts UX on flaky networks, and requires more moving parts (e.g., websockets) to feel responsive.
  • Debate over whether HTMX’s “hypermedia-first” approach is genuinely simpler, or just shifts complexity.

Broader web dev philosophy

  • Several argue most current SPAs are unnecessary; users mainly want fast, reliable pages, not maximal interactivity.
  • Others counter that many modern apps genuinely need richer client‑side behavior and that React/Vue/Svelte better support evolving requirements.
  • General agreement: HTMX is powerful for small-to-medium, server-centric apps; poor fit as a primary tool for large, state-heavy SPAs.