</> Htmx – The Fetch()ening

Original Article ↗ Hacker News Discussion ↗

Versioning, Stability, and “htmx 4.0” Naming

  • Strong approval for the promise that htmx 1/2 will be supported indefinitely; seen as rare in a churn-heavy ecosystem.
  • Mixed reactions to skipping 3.0 and jumping to 4.0 to remain “technically correct”: many find it funny, others think it may cause needless confusion (PHP 6 analogy); some say a simple mea culpa 3.0 would be clearer.
  • A few argue that batching many breaking changes into one major release is the wrong way to achieve stability, comparing it to Python 3; they advocate Django-style gradual deprecations and more frequent majors.
  • At least one commenter says this big-bang major bump makes them avoid adopting htmx for new work, failing their “stability test”. Others are happy as long as previous versions remain usable.

Core Philosophy: HTML-First, Not JSON

  • Complaint: htmx doesn’t auto-parse JSON in hx-on::after-request callbacks.
  • Response: this is by design—htmx is meant for HTML hypermedia responses, not JSON APIs. Many emphasize that this HTML-centricity is a core design choice, not an omission.
  • 4.0 will expose the full request/response/swap pipeline and allow custom fetch implementations per-trigger, which should make JSON or other custom flows possible without changing the HTML-first philosophy.

fetch(), Streams, and Morphing

  • Move from XMLHttpRequest to fetch() is welcomed; it simplifies internals and enables readable streams for SSE/streaming partial updates.
  • 4.0 will integrate morph-based swaps (inner/outer) into core, made feasible by the fetch refactor; some question whether this belongs in core vs extension.
  • Example patterns show per-request fetch overrides via hx-on:htmx:config:request, enabling mocking or custom transport without global monkey-patching.

htmx vs Datastar: Overlap and Tradeoffs

  • Datastar is repeatedly mentioned as a more general, plugin-driven alternative with built-in SSE, signals, DOM morphing, and smaller core; some describe htmx 4 as “Datastar-lite”.
  • Pro/datastar skeptics worry about non-FOSS/pro features and potential rugpulls; defenders point to nonprofit ownership, MIT core, and pluggable architecture.
  • Technical debate:
    • Pro-htmx side: htmx’s constrained request/response model and HTML fragments are simpler for typical CRUD apps, easier to reason about and debug, and integrate well with URL/history semantics.
    • Pro-Datastar side: a more generalized, event/signal/stream-driven model handles both simple and complex use cases; they argue htmx’s attribute surface is actually larger and less composable.
  • Significant disagreement over URL/history: htmx users see “URL as state” and history updates as central to hypermedia; Datastar’s authors reportedly treat history-pushing as an antipattern, which several commenters strongly reject.

Attribute Inheritance and Naming Bikeshedding

  • 4.0 flips inheritance to opt-in; prior implicit inheritance caused confusion and support load.
  • Long subthread bikesheds the hx-inherited name; alternatives like inherit, inheritable, propagate, and cascade are suggested, with various jokes attached.

General Reception

  • Many praise the essay’s clarity and the direction of htmx 4.0, especially open request cycle and streaming.
  • Others express concern that the library is growing more complex, drifting away from its original minimalism.