URL-Driven State in HTMX

Original Article ↗ Hacker News Discussion ↗

Value of URL‑Driven State

  • Many commenters endorse encoding view state in the URL (query params or hash) as the default for web apps: it enables bookmarking, sharing, deep‑linking, and “object permanence” of UI.
  • Pattern is praised as “fantastic UX” and a rediscovery of how 1990s/early‑2000s web apps worked, before SPAs obscured it.
  • Use cases called out: filters, pagination, configuration wizards, active searches, and notification toasts.

Implementations & Tooling

  • SPA side: people mention React Router’s useSearchParams, wrapper hooks that support multiple backends (memory, localStorage, Redux, URL), and libraries like nuqs and TanStack Router that give typed, debounced URL state.
  • HTMX side: hx-push-url plus server‑driven HTML; hx-swap-oob used for out‑of‑band updates like toast notifications or updating other page regions.
  • Some use custom “sync params” mechanisms to propagate changed query params to all links on a page.
  • Other techniques: using location.hash for larger client‑only state, Rison or compressed JSON in fragments, or shortening via server‑side IDs.

Limits, Edge Cases, and Tradeoffs

  • Bookmarkability and pagination generate debate:
    • Page‑number pagination over mutable data (“page=2”) is often not semantically meaningful or stable.
    • Cursor/token pagination can be better for “start from item X,” but interacts badly with changing sort keys (e.g., price).
    • Truly immutable lists require time/version identifiers and archival storage, which most human users don’t actually want.
  • One commenter rejects “URL as single source of truth,” arguing there are distinct in‑progress, committed, and loaded states that apps must model explicitly.
  • Others accept loss of some “edge‑case correctness” in exchange for simplicity, arguing backend query speed can mitigate many UX issues.
  • URL size limits (~2KB typical) and hash‑based hacks are acknowledged; stuffing large blobs into URLs or hash is seen as fragile at scale.

SPAs vs SSR/HTMX and Broader Philosophy

  • Strong current in favor of SSR + HTMX/Alpine/Livewire/Django, arguing:
    • Less client complexity; state naturally lives in URLs and on the server.
    • Performance is often “good enough” on modern connections; many SPA stacks are seen as over‑engineered “complexity merchants.”
  • Counterpoints:
    • Complex, highly interactive apps (maps, Figma‑style tools, webmail) still benefit from heavy client‑side logic and SPA‑like patterns.
    • Modern SSR frameworks and tools (React Server Components, Remix, etc.) are trying to merge strong URL semantics with rich interactivity.