Datastar: Web Framework for the Future?

Original Article ↗ Hacker News Discussion ↗

Performance and Demo Issues

  • Several commenters report the official TODO demo as very slow and unreliable (laggy toggling, failed adds/deletes) even on fast wired connections.
  • This is largely attributed to the demo running on a constrained Fly.io free-tier instance that buckled under HN traffic; the author temporarily removed it and pointed to another demo on a beefier VPS.
  • A multiplayer Game of Life demo intentionally sends ~2,500 <div>s every 200ms via compressed SSE as a DOM stress test.
  • Some see this as an “everything looks like a nail” approach; others argue it demonstrates that network and Datastar aren’t the bottleneck when combined with Brotli and tuned compression windows.
  • There’s debate around Datastar marketing claims like “microsecond updates”: critics say this ignores real-world latency; defenders distinguish server update rate from RTT but agree the copy could be clearer.

Architecture: Server-Driven, Signals, SSE

  • Datastar is pitched as a server-driven, hypermedia-oriented system with a tiny core that turns data-* attributes into reactive “signals” and wires them to plugins (SSE, morphing, etc.).
  • Author positions it between SPA and MPA: most state lives on the server, but the frontend needs fine-grained reactivity. Others argue more state should live locally (memory/IndexedDB) for responsiveness and offline/local-first use cases.
  • Signals are discussed in terms of dependencies, publishers/subscribers, and FRP concepts, with some confusion vs observables.
  • SSE is central for push-based, multiplayer-style updates; some propose service-worker-based approaches for offline/local-first while still using Datastar’s templating model.

Security and CSP Concerns

  • A recurring criticism is Datastar’s apparent hard requirement for unsafe-eval, seen as “a gaping hole” in strict CSP setups.
  • Comparisons: htmx can disable eval; Alpine has a CSP mode; SvelteKit can be CSP-compliant. Some argue Datastar is different because of its evaluation model.
  • The author mentions ideas for per-language CSP middleware with hashed script content but treats CSP worries as partly a “red herring” unless user HTML is rendered without sanitization.
  • Other commenters push back, saying strict CSP is a real requirement for clients and is a blocker to adopting Datastar today.

Comparisons to HTMX, Hotwire, and Other Stacks

  • Multiple people came from HTMX+Alpine/hyperscript and felt complexity scales poorly; Datastar’s unified signal model is seen as cleaner for highly interactive apps.
  • One detailed comparison with Turbo/Hotwire highlights: polling vs push, morphing limitations, need for extra JS (Stimulus), and difficulties off-Rails. Datastar is described as smaller, faster, simpler, with better docs/examples.
  • Some note Datastar embraces HTMX-style out-of-band swaps as a first-class concept, and began as an attempt to influence a hypothetical HTMX 2.
  • Others view Datastar as just another iteration of server-rendered frameworks from 10–15 years ago, questioning whether this is really “the future.”

Progressive Enhancement vs JS-Dependent Apps

  • A key philosophical divide: htmx’s appeal includes graceful degradation when JS fails; Datastar explicitly rejects progressive enhancement as a priority.
  • The author argues modern “apps” should assume HTML+CSS+JS and that if you truly want links/forms-only, a plain MPA is better.
  • Critics see this as engineeringly fragile: robust systems should fail gracefully (including when JS/CSS don’t load) and not be all-or-nothing.
  • There’s a side debate over whether catering to JS-disabled users is about real users or just opinionated developers, versus PE as generally sound engineering.

Adoption, Tooling, and Backend Integration

  • Several commenters are enthusiastic, praising the article and docs, and plan to try Datastar on prototypes or hobby projects.
  • People highlight its language-agnostic backends (Go, Ruby, etc.), though one Django developer says SSE is “far from” trivial there compared to htmx’s minimal backend changes.
  • Examples requested: beyond TODOs, the Datastar site itself and the multiplayer Game of Life demo are pointed to as non-trivial references; community boilerplates exist.
  • Some are attracted to Datastar as a tiny, plugin-based “almost frameworkless” core that avoids heavy JS ecosystems and npm dependency churn; others remain wary and prefer to wait until (or if) it becomes unavoidable.

Broader Reflections on Web Dev Trends

  • Commenters lament that “the web framework of the future” is often whatever Vercel/YouTubers promote, not necessarily what’s technically superior.
  • There’s nostalgia for older hypermedia ideas (e.g., Hydra) and enthusiasm for a renewed hypermedia ecosystem (HTMX, Datastar, Alpine AJAX, etc.).
  • Some argue the future will be less JS-centric or more WASM-based, though others note the current WASM tooling/UX still lags mainstream JS frameworks.