Datastar Framework Deep Dive: A New Paradigm for Hypermedia-Driven State Management

Introduction: The Dilemma of Frontend State Management

In modern frontend development, state management has become an unavoidable challenge for nearly every team. From Redux to Zustand, from Vuex to Pinia, we've invented tool after tool to manage state in frontend applications. The evolution of these tools itself reflects the community's ongoing reflection on complexity — Redux was born in 2015, introducing concepts of unidirectional data flow and immutable state, but its massive boilerplate code exhausted developers; MobX simplified things with observable objects; Zustand further compressed global state management into a minimal API; and in the Vue ecosystem, Vuex's mutations/actions distinction was replaced by Pinia's more intuitive design. Yet a question worth pondering remains: Have we been putting state in the wrong place?

In the SSW 2026 talk Put State in the Right Place, Delaney Gillilan presented a rather disruptive perspective, using a hypermedia framework called Datastar to re-examine where frontend state should actually reside. This topic has sparked considerable discussion on Reddit and other tech communities, drawing increasing attention from developers toward the revival of hypermedia architecture.

What Is Datastar? The Core Positioning of a Hypermedia Framework

Datastar's Design Philosophy

Datastar is a lightweight hypermedia-driven framework whose core philosophy aligns with the recently resurgent HTMX, though it makes its own distinctive trade-offs in design philosophy and technical implementation.

The core idea behind a hypermedia framework is: let the server be the authoritative source of truth for state, while the frontend only handles rendering and interaction feedback. This concept is rooted in the HATEOAS (Hypermedia as the Engine of Application State) constraint of REST architecture — the client doesn't need to hard-code any API endpoints or state transition logic in advance, but instead discovers available operations through hypermedia links returned by the server. It's like browsing the web where clicking a link takes you to the next page without needing to know all URLs beforehand. This was the default way the web worked in the traditional era, but it was gradually forgotten as SPAs rose to prominence. What HTMX and Datastar do is essentially reactivate this classic principle using modern technology.

This stands in stark contrast to the current mainstream SPA (Single Page Application) paradigm — in SPAs, massive amounts of business state are moved to the browser, the frontend must maintain a complex state tree, and keep it synchronized with the backend through APIs.

Datastar aims to break through this complexity. Through declarative HTML attribute bindings combined with server push mechanisms (such as SSE, Server-Sent Events), it achieves efficient frontend-backend state coordination while keeping the vast majority of state logic where it belongs — on the server side.

A few more words about the SSE mechanism: SSE is a technology defined in the HTML5 specification for one-way server-to-client data pushing. Unlike WebSocket's bidirectional communication, SSE is built on regular HTTP connections, allowing the server to continuously send event streams to the client. It features automatic reconnection, native compatibility with HTTP/2 multiplexing, no need for special protocol upgrades, and can be correctly handled by standard proxies and load balancers. For Datastar, SSE is the ideal data push channel — the server can proactively push pre-rendered HTML fragments to the client when state changes, without requiring client-side polling or complex WebSocket connection management logic.

Datastar vs. HTMX

Developers familiar with HTMX will notice that Datastar shares a highly similar philosophy: both emphasize using hypermedia as the engine of application state (a modern practice of HATEOAS thinking). However, Datastar goes further by building in support for Reactive Signals, enabling fine-grained local state management on the frontend without letting client-side state grow unbounded.

Reactive signals are a fine-grained reactive primitive that has regained popularity in frontend frameworks in recent years. Unlike React's virtual DOM diffing mechanism, Signals establish a dependency graph and precisely update only the affected DOM nodes when values change, without triggering a full component re-render. This concept can be traced back to Knockout.js's observables and has been re-adopted by modern frameworks like SolidJS, Preact Signals, and Angular Signals. Datastar's built-in signal support means developers can still enjoy efficient reactive updates when handling small amounts of local UI state (such as animation transitions or instant form validation feedback) without importing a full client-side framework.

In other words, Datastar attempts to find a more reasonable balance point between "pure server rendering" and "pure client-side state."

Core Argument: Put State in the Right Place

Three Categories of State Ownership

Gillilan's core argument in the talk can be summarized as a reclassification of state "ownership." State can be roughly divided into three categories:

• Server State: True business data such as user information, orders, and inventory. This type of state should be authoritatively managed by the server — the frontend should not replicate and maintain it on its own.
• UI State: Pure interface interaction state, such as whether a dropdown menu is expanded or tab switching. This type of state naturally belongs to the frontend.
• URL State: State that can be expressed and shared via URL, such as pagination, filter criteria, and search keywords. This type of state should be encoded into the URL whenever possible.

Much of the complexity in frontend applications comes precisely from incorrectly moving server state to the client, which then necessitates additional caching, invalidation, and synchronization logic. Datastar's proposition is: let each type of state return to its most appropriate location.

Why State Ownership Matters So Much

When we force business state to remain on the client side, we inevitably face a series of thorny problems: stale data, cache invalidation, optimistic update rollbacks, and more. These problems spawned libraries like React Query and SWR, specifically designed for "server state management" — which is itself a signal that we've acknowledged this state shouldn't be entirely the client's responsibility.

The popularity of React Query (now renamed TanStack Query) and SWR is a telling phenomenon in itself. The core features of these libraries — data fetching, caching, background refresh, optimistic updates — are all essentially addressing the same problem: how to keep the client's copy of server data fresh. They introduce sophisticated mechanisms like stale-while-revalidate strategies, automatic garbage collection, and request deduplication. But if we step back and think, the root cause of all this complexity is: we chose to cache server state on the client. The radical approach of hypermedia frameworks is to dissolve this problem entirely — no client-side cache means no cache invalidation headaches.

The hypermedia framework approach avoids this issue at its source: since the server is the authoritative source of state, let the server push pre-rendered fragments directly, and the frontend simply performs straightforward replacements. This greatly simplifies the developer's mental model.

Technical Trend: The Revival of Hypermedia Architecture

From Over-Engineering Back to Simplicity

Over the past decade, frontend engineering complexity has grown exponentially. This bloat manifests across multiple dimensions: build tools have gone through multiple generations from Grunt/Gulp to Webpack to Vite/Turbopack; CSS solutions evolved from vanilla to Sass to CSS-in-JS to Tailwind; TypeScript becoming the de facto standard brought learning costs for generics, conditional types, and other advanced features; and rendering strategy choices like SSR/SSG/ISR have made deployment architecture complex as well. A typical modern frontend project's node_modules might contain thousands of dependency packages, and the build configuration files themselves require dedicated personnel to maintain.

Build toolchains, state management, type systems, and SSR/SSG solutions stacked upon each other have made many otherwise simple applications bloated. Hypermedia frameworks represented by HTMX and Datastar are precisely a reflection on and correction of this "over-engineering" wave.

Their value lies not in replacing heavyweight frameworks like React and Vue, but in reminding us: not every application needs the full SPA arsenal. For applications centered on content and form interactions, hypermedia solutions can often achieve equivalent user experiences with minimal code. This complexity is justified for large interactive applications, but for many applications primarily focused on information display and form submission, it's clearly over-engineering.

Datastar's Applicable Scenarios and Boundaries

Of course, hypermedia frameworks are not a silver bullet. For highly interactive applications requiring complex offline capabilities or rich client-side computation (such as online design tools or complex dashboards), traditional rich-client approaches still hold the advantage.

Datastar is better positioned for:

• Content-oriented websites primarily using server rendering
• Applications needing real-time updates but with relatively simple interactions
• Teams looking to reduce frontend complexity and minimize JavaScript bundle size

Developers need to determine where state should actually reside based on specific business scenarios — which is precisely the theme of the talk.

Conclusion: Rethinking Where Frontend State Belongs

Delaney Gillilan's talk and the Datastar framework are essentially a "back to fundamentals" moment for modern frontend architecture. It doesn't invent any entirely new technology, but rather re-emphasizes a principle many have forgotten: state should be placed as close to its authoritative source as possible.

In an era of proliferating frameworks and ever-increasing complexity, this kind of return-to-basics thinking is especially valuable. Whether or not you adopt Datastar in your next project, understanding the classification logic of "state ownership" can help you make clearer decisions in architectural design.

For developers following frontend evolution trends, Datastar is worth adding to your technology radar — it may not become mainstream, but the hypermedia movement it represents is quietly changing our understanding of "what the frontend should do."