I switched from Htmx to Datastar

Original Article ↗ Hacker News Discussion ↗

Datastar vs HTMX / Hotwire – Core Technical Differences

  • Datastar is seen as “HTMX but more opinionated”:
    • Uses SSE heavily (including for request/response flows), supports long‑lived connections and “immediate mode” style rerendering.
    • Uses ID‑based morphing (Idiomorph‑style) by default: server returns HTML fragments with IDs and the client patches matching elements, often for the whole body.
    • Includes a built‑in reactivity/signals layer (Alpine‑like) in data-* attributes, aiming to reduce JS “glue code.”
  • HTMX:
    • HTML‑driven: swap behavior is normally specified in attributes (hx-target, hx-swap, hx-swap-oob, etc.).
    • SSE and websockets exist as extensions; OOB updates can also target multiple areas but require explicit attributes in each snippet.
    • No built-in client state layer; typically combined with Alpine/Stimulus.
  • Hotwire/Turbo is mentioned as conceptually closer to Datastar in that the server often decides what gets replaced and where, but its ergonomics and docs are criticized.

Architecture & Developer Experience

  • Supporters like Datastar’s “server owns the view” model: one long‑lived SSE endpoint renders the user’s field of view; whole views are rerendered and morphed, leveraging compression and batching.
  • Critics worry about:
    • Backend code needing intimate knowledge of HTML IDs, echoing old RJS/Xajax patterns.
    • Presentation logic scattered across backend functions and HTML, making large apps hard to reason about.
    • Over‑emphasis on SSE when many apps just need simple request–response updates.
  • Some note that most Datastar patterns (including OOB‑style updates) are technically achievable in HTMX with different defaults.

Datastar Pro, Licensing, and Trust

  • A major thread theme is backlash over Datastar Pro: some previously free plugins/behaviors (e.g. data-replace-url, inspector, animation utilities) now in a $299 “Pro” tier.
  • Users who had built against beta features describe this as a “bait and switch” or “rug pull”; worry it signals future paywall creep and makes the project risky for long‑term adoption or enterprise use.
  • Defenders counter:
    • Core is MIT and “done soon”; Pro only contains optional or even “anti‑pattern” features that are support burdens.
    • Old implementations remain in Git history and can be forked; nothing was relicensed.
    • Maintainers need sustainable funding; open‑core/freemium is framed as realistic vs “sell support” models that rarely work.
  • Debate widens into open‑source ethics: whether publishing code creates any social obligation beyond the license; whether moving features behind paywalls is acceptable; and how much users “owe” maintainers vs vice versa.

Community Tone & Governance

  • Multiple commenters describe negative personal experiences with the project’s Discord/Reddit: feeling mocked, dismissed, or told to “fork it” or “go away” when questioning design or pricing.
  • Others defend the project culture as blunt but focused on technical rigor, arguing that critics are mostly non‑users engaging in “performative outrage.”
  • Several note that maintainers’ public combative style and licensing decisions, more than the tech itself, make them hesitant to adopt Datastar.

Broader Context: Hypermedia vs SPAs

  • Many see Datastar/HTMX/Hotwire as part of a pendulum swing back to server‑rendered HTML with “sprinkles” instead of full SPAs: fewer APIs, smaller codebases, less JS, easier dashboards/forms.
  • Some report failed attempts to scale HTMX apps (rigid Go code, confusing templates), preferring Phoenix LiveView or classic SSR frameworks.
  • Others highlight successful Datastar demos (multiplayer Game of Life, giant checkbox grids) running on tiny servers without Pro features, as proof the core is powerful enough.