Htmx 2.0.4 Released

Original Article ↗ Hacker News Discussion ↗

Patch release behavior & semantic versioning

  • A change around htmx.ajax default behavior sparked debate about whether it belonged in a patch release.
  • Concern: calls without target/source previously had no visible effect; changing this could suddenly replace the whole body, especially for tracking-style calls.
  • Clarification later: 2.0.3 introduced a bug that broke the “no source/target” default; 2.0.4 restores intended behavior and fixes an earlier issue where bad selectors could wipe the page.
  • Broader semver discussion:
    • Some view semver as aspirational and inherently imperfect, since “bug vs feature” is decided by users in practice.
    • Others insist breaking changes in patch releases erode trust and make versioning useless.

History cache: localStorage vs sessionStorage/memory

  • Question raised: why store htmx history snapshots in localStorage instead of sessionStorage or memory, given persistence and security implications.
  • Arguments for current design:
    • Memory wouldn’t survive refresh; sessionStorage may not survive tab close or behave consistently across browsers.
    • Goal was to mimic browser behavior that caches across tabs and navigations.
  • Critics:
    • localStorage can retain data longer than expected and consume space for mostly-MPA sites.
    • sessionStorage as default plus better documentation of risks is suggested.
  • Mitigations mentioned: disabling history per page and/or setting history cache size to zero.

Relationship to intercooler.js & community memes

  • Some initially frame htmx as a copy of intercooler.js; others note it is effectively a continuation by the same creator.
  • A mock “feud” between htmx and intercooler.js accounts is described as a joke.
  • The “CEO of htmx” meme (anyone can be one via a gag site) recurs in lighthearted subthreads.

Use cases, limits, and alternatives

  • Supporters highlight:
    • Very low-friction interactivity for MPAs (filters, upvotes, partial reloads, websocket-driven UIs).
    • No need for SPA frameworks or build steps; backend teams can own the UI.
  • Critics emphasize:
    • Client-heavy state (calculators, sliders, complex widgets) can feel awkward if every change hits the server; frameworks like React/Svelte/Alpine are preferred there.
    • Once a JS framework is used, htmx may feel redundant.
  • Counterpoint: htmx is “just” a hypermedia/HTML-first ajax layer and is meant to be combined with JS where needed, not to eliminate JS entirely.

Coupling, state, and alternatives

  • One line of criticism:
    • htmx tightly couples backend and HTML, reminiscent of older PHP-style code.
    • Returning HTML from ajax can duplicate rendering logic between server and client, making state management harder as apps grow.
  • Suggested alternatives: Inertia.js (SPA frameworks without explicit APIs) and petite-vue (lightweight progressive enhancement).
  • Response from htmx side:
    • Hypermedia intentionally couples at the application layer but decouples at the network layer.
    • Many multi-element updates and state-sync problems can be handled via documented htmx patterns.
    • Not all features are appropriate for a hypermedia-driven approach; guidance exists on when to use it.

Tone of the thread

  • Mix of enthusiasm (“boring” stable release, “htmx on a pedestal”, reduced complexity) and skepticism (scalability, state, patch-level changes).
  • Numerous jokes compare htmx vs React in absurd contexts, underlining the ongoing culture clash between SPA and hypermedia-first mindsets.