Datastar Framework Explained: A New Hypermedia-Driven Paradigm for State Management
Datastar redefines frontend state management by keeping server state where it belongs—on the server.
Datastar is a lightweight hypermedia framework that challenges the SPA status quo by keeping business state on the server and using SSE and reactive signals for efficient frontend-backend coordination. This article explores its design philosophy, compares it with HTMX, classifies state into server, UI, and URL categories, and discusses when hypermedia architecture is the right choice over traditional rich-client approaches.
Introduction: The Dilemma of Frontend State Management
In modern frontend development, state management has become an almost unavoidable challenge for 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 the concepts of unidirectional data flow and immutable state, but its 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 reflecting on 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 live. This topic has sparked considerable discussion on Reddit and other tech communities, drawing more developers' attention to the resurgence of hypermedia architecture.
What Is Datastar? The Core Positioning of a Hypermedia Framework
Datastar's Design Philosophy
Datastar is a lightweight hypermedia-driven framework. Its core philosophy aligns closely with the recently repopularized HTMX, though it makes its own distinct trade-offs in design 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 handles only rendering and interaction feedback. This idea 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; instead, it discovers available operations through hypermedia links returned by the server. Just like browsing a website where clicking links takes you to the next page without needing to know all the URLs in advance. This principle was the default way the web worked in the traditional era but was gradually forgotten as SPAs rose to prominence. What HTMX and Datastar are doing is essentially reactivating this classic principle with modern technical means.
This stands in stark contrast to the current mainstream SPA (Single Page Application) paradigm—where a large amount of business state is moved to the browser, the frontend needs to maintain a complex state tree, and stays 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.
SSE deserves some additional explanation: SSE is a technology defined in the HTML5 specification for one-way server-to-client data pushing. Unlike WebSocket's bidirectional communication, SSE operates on top of regular HTTP connections, allowing the server to continuously send event streams to the client. It features automatic reconnection, native compatibility with HTTP/2 multiplexing, requires no 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, eliminating the need for client-side polling or complex WebSocket connection management logic.
Datastar vs. HTMX
Developers familiar with HTMX will notice that Datastar is highly similar in philosophy: both emphasize using hypermedia as the engine of application state (a modern practice of HATEOAS thinking). However, Datastar goes a step further by building in support for Reactive Signals, enabling fine-grained local state management on the frontend without letting client-side state grow unboundedly.
Reactive Signals are a fine-grained reactive primitive that has regained popularity in frontend frameworks in recent years. Unlike React's virtual DOM diff mechanism, Signals build a dependency graph, precisely updating only the affected DOM nodes when values change, without triggering re-renders of entire components. This concept can be traced back to Knockout.js's observables and has since been readopted 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 needing to introduce a full client-side framework.
In other words, Datastar tries to find a more reasonable balance between "pure server rendering" and "pure client-side state."
Core Argument: Put State in the Right Place
Three Categories of State Ownership
The central argument in Gillilan's talk can be summarized as a reclassification of state "ownership." State can be broadly divided into three categories:
- Server State: True business data such as user information, orders, inventory, etc. This type of state should be authoritatively managed by the server—the frontend should not replicate or maintain it independently.
- UI State: Purely interface interaction state, such as whether a dropdown menu is expanded, tab switching, etc. This type of state naturally belongs to the frontend.
- URL State: State that can be expressed and shared through URLs, such as pagination, filter conditions, search keywords, etc. 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 creates the need for 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 issues: stale data, cache invalidation, optimistic update rollbacks, and more. These problems gave rise to libraries like React Query and SWR, which are specifically designed for "server state management"—this itself is a signal: we're acknowledging that these states shouldn't be entirely the client's responsibility.
The popularity of React Query (now renamed TanStack Query) and SWR is a phenomenon worth pondering. The core functionality of both libraries—data fetching, caching, background refresh, optimistic updates—essentially addresses 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 of all this complexity is: we chose to cache server state on the client. The radical stance 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 the 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 dramatically simplifies the developer's mental model.
Technical Trend: The Resurgence 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 approaches evolved from vanilla CSS to Sass to CSS-in-JS to Tailwind; TypeScript becoming the de facto standard brought learning costs for advanced features like generics and conditional types; and rendering strategy choices like SSR/SSG/ISR have made deployment architectures 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 maintenance effort.
Build toolchains, state management, type systems, and SSR/SSG solutions stacked on top of each other have made many inherently simple applications bloated. Hypermedia frameworks represented by HTMX and Datastar are a reflection on and correction of this wave of "over-engineering."
Their value lies not in replacing heavyweight frameworks like React or Vue, but in reminding us: not every application needs the full SPA arsenal. For applications primarily 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 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 suited for:
- Content-focused websites primarily relying on server rendering
- Applications that need real-time updates but have relatively simple interactions
- Teams looking to reduce frontend complexity and minimize JavaScript bundle size
Developers need to determine where state should live based on specific business scenarios—which echoes the talk's central theme.
Conclusion: Rethinking Where Frontend State Belongs
Delaney Gillilan's talk and the Datastar framework are essentially a "return to fundamentals" for modern frontend architecture. It doesn't invent any entirely new technology but re-emphasizes a principle many have forgotten: state should be placed as close as possible to its authoritative source.
In an era where frameworks emerge endlessly and complexity keeps climbing, this kind of back-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 more clear-headed decisions in architectural design.
For developers paying attention to 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."
Key Takeaways
Related articles
Using RL to Please the Reward Model: The Reward Hacking Concern Behind Soaring Elo Scores
When RL continuously optimizes models to please reward models, do soaring Elo scores truly represent capability gains? A deep dive into Reward Hacking in RLHF, Goodhart's Law in AI, and industry countermeasures.
From FTX to AI: A Warning About the Collapse of Trust in Tech
From the FTX Future Fund collapse to AI, exploring tech's trust crisis, résumé laundering, and lack of accountability when scandal-linked figures move into key AI roles.
AI Agents Running a Real Company: Experiment Results and Capability Boundary Analysis
What happens when AI agents are tasked with running a real company? This analysis examines agent performance, critical shortcomings, and practical enterprise deployment advice.