Building a single-page app with Htmx

Original Article ↗ Hacker News Discussion ↗

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.