How HTMX and Declarative Partial Updates Could Finally Deliver the Promise of Server-Driven UI
What if the future of web applications isn't more JavaScript—but better HTML?
For the last decade, frontend development has largely revolved around a single idea:
Ship less HTML, ship more JavaScript.
React, Vue, Angular, Next.js, Remix, Solid, and countless other frameworks have spent years moving application logic into the browser.
And to be fair, they solved real problems.
Users expect applications to feel instant. They expect rich interactions, real-time updates, and seamless navigation.
But in solving those challenges, we also introduced a new class of complexity:
- Hydration
- Massive JavaScript bundles
- Client-side state management
- Build pipelines
- Data-fetching layers
- REST and GraphQL orchestration
- Server/client rendering mismatches
Sometimes it feels like we've spent a decade building abstractions to compensate for the limitations of previous abstractions.
Then something interesting happened.
Chrome introduced Declarative Partial Updates (DPU), an emerging set of browser primitives designed to make HTML streaming and partial UI updates a native browser capability.
At the same time, a lot of developers started rediscovering ideas championed by tools like HTMX:
Maybe HTML was never the problem.
And when you combine those two ideas, a fascinating possibility begins to emerge.
Not the death of React.
Not the end of SPAs.
But the return of server-driven UI as a serious architectural option.
Remember When HTML Was Enough?
Traditional web applications were remarkably simple.
Browser
↓
Request
↓
Server renders HTML
↓
Browser displays page
The browser received UI.
The server owned the application state.
The rendering model was straightforward.
Then came Single Page Applications.
Browser
↓
Download JavaScript
↓
Call API
↓
Fetch JSON
↓
Update State
↓
Render Components
This gave us incredible user experiences.
But it also introduced a more complex rendering pipeline:
Backend
↓
REST / GraphQL
↓
JSON
↓
Client State
↓
Framework Runtime
↓
Virtual DOM
↓
Actual DOM
The browser stopped receiving UI.
The browser started receiving data.
And suddenly every application needed a frontend framework.
Why React Developers Should Care About HTMX
Most React developers dismiss HTMX as a niche library.
I used to think the same thing.
After all, React solved a lot of problems:
- Component composition
- State-driven rendering
- Rich interactions
- Complex application workflows
So why would anyone want to go back?
The interesting part is that HTMX isn't really trying to take us backwards.
It's asking a different question:
What if some of the complexity we've accepted as normal isn't actually necessary?
Instead of:
const cart = await fetch("/api/cart");
setState(cart);
And then:
<Cart items={cart} />
HTMX lets you write:
<button
hx-post="/cart/add"
hx-target="#cart">
Add to Cart
</button>
The server responds with:
<div id="cart">
5 items
</div>
The browser updates.
No JSON transformation.
No client-side templates.
No component reconciliation.
Just HTML.
For years, that felt like an alternative approach.
With Declarative Partial Updates, it suddenly starts feeling aligned with where browsers themselves might be heading.
Why Developers Are Rediscovering Server-Driven UI
For years the industry message was clear:
Push more logic to the frontend.
But many teams are discovering an uncomfortable truth.
A large percentage of business applications are fundamentally:
- Forms
- Tables
- Dashboards
- Reports
- Internal tools
- Admin panels
- CRUD workflows
For these applications, the complexity of a large SPA often outweighs its benefits.
The server already knows:
- The state
- The permissions
- The business logic
- The data
Why constantly serialize everything into JSON only to reconstruct the UI in the browser?
Why send data when we could send the interface itself?
This is where HTMX becomes interesting.
And this is where Declarative Partial Updates become genuinely exciting.
The Missing Piece
HTMX is excellent at updating portions of a page.
However, there has always been one limitation.
Browsers traditionally process HTML in a mostly linear fashion.
Imagine a dashboard:
+----------------------------+
| Navigation |
+----------------------------+
| Revenue Widget |
+----------------------------+
| AI Insights |
+----------------------------+
| Notifications |
+----------------------------+
Let's say:
- Revenue Widget takes 100ms
- Notifications take 200ms
- AI Insights take 5 seconds
Historically, you had a few options:
- Wait for everything
- Make multiple requests
- Build custom streaming systems
- Use a large frontend framework
None are particularly elegant.
This is where Declarative Partial Updates become extremely interesting.
What Declarative Partial Updates Change
Declarative Partial Updates introduce browser-native mechanisms for inserting content into predefined locations as it becomes available.
Conceptually:
<div>
<?marker name="revenue"?>
</div>
Later:
<template for="revenue">
<h2>$2.1M Revenue</h2>
</template>
The browser inserts the content when it arrives.
The key innovation isn't the syntax.
It's the architectural shift.
For the first time, the browser can participate in incremental UI assembly without requiring large amounts of client-side JavaScript.
Instead of waiting for everything to finish rendering, content can arrive when it's ready.
HTML becomes more dynamic.
The browser becomes more capable.
Loading States Become Surprisingly Elegant
One aspect of Declarative Partial Updates that doesn't get enough attention is how naturally they can handle loading states.
In modern React applications, we often write:
if (isLoading) {
return <Spinner />;
}
Or:
<Suspense fallback={<Spinner />}>
<Dashboard />
</Suspense>
With DPU, placeholders become part of the HTML itself.
Imagine:
<section class="revenue-card">
<div class="shimmer title"></div>
<div class="shimmer amount"></div>
<?marker name="revenue"?>
</section>
The user immediately sees a skeleton UI.
Not a blank screen.
Not a spinner.
A shape of the final experience.
When data arrives:
<template for="revenue">
<div class="revenue-card">
<h3>Total Revenue</h3>
<h2>$2.1M</h2>
</div>
</template>
The browser replaces the placeholder.
No loading state variables.
No client-side orchestration.
No reconciliation process.
What's particularly interesting is that even the loading state becomes server-driven.
Dashboard Appears
↓
Revenue Loaded
↓
Notifications Loaded
↓
AI Insights Loaded
This feels surprisingly similar to React Suspense.
Except it's happening through browser-native HTML primitives.
HTMX + Declarative Partial Updates = A New Architecture
Imagine the following flow:
User Action
↓
HTMX Request
↓
Backend
↓
REST / GraphQL Services
├── Revenue Service
├── AI Service
└── Notification Service
↓
HTML Fragments Stream Back
↓
Browser Updates Regions
Notice what's missing:
- Redux
- React Query
- Apollo Client
- GraphQL Cache Management
- State Synchronization Layers
The server owns the UI.
The browser assembles it.
HTMX handles interactions.
Declarative Partial Updates handle streaming.
That's an incredibly compelling model.
Why This Could Matter To React Developers
This isn't interesting because React is going away.
It's interesting because React developers have spent years solving problems around:
- Streaming
- Suspense
- Server Components
- Partial Rendering
- Hydration
And suddenly the browser itself is evolving in a similar direction.
The real question isn't:
Will DPU replace React?
The real question is:
Could future React architectures leverage browser-native streaming primitives instead of relying entirely on framework runtimes?
That's a conversation worth paying attention to.
The Killer Use Case: AI Applications
AI applications are naturally streamed.
Today's architecture often looks like:
LLM
↓
Token Stream
↓
JSON
↓
Frontend State
↓
React Re-Renders
↓
DOM Updates
What if it instead looked like this?
LLM
↓
Server Generates HTML
↓
Browser Streams Content
Imagine:
<?marker name="response"?>
And then:
<template for="response">
<p>The answer is...</p>
</template>
The browser updates immediately.
No JSON mapping.
No state synchronization.
No virtual DOM work.
Just streamed UI.
Ironically, some of the most modern applications on the internet might benefit from returning to server-driven rendering principles.
HTMX Has Limits Too
It's easy to read articles like this and conclude that HTMX is the answer to everything.
It isn't.
HTMX shines when:
- The server owns the state
- UI can be represented as HTML fragments
- Most interactions involve server communication
But not every application fits that model.
HTMX becomes less compelling when dealing with:
- Complex local state
- Drag-and-drop editors
- Canvas-heavy applications
- Offline-first experiences
- Real-time collaborative applications
- Highly interactive visual tooling
In those environments, React's component model and client-side state management remain extremely valuable.
That's why I don't see HTMX competing with React.
I see it competing with unnecessary complexity.
The Architecture I'm Most Excited About
If this vision matures, my dream stack looks something like this:
PostgreSQL
↓
Backend Services
↓
REST / GraphQL
↓
Server Rendering Layer
↓
HTMX
↓
Declarative Partial Updates
↓
Browser
For highly interactive islands:
React
↓
Small Client Components
Everything else stays server-driven.
Benefits
✅ Faster initial rendering
✅ Smaller JavaScript bundles
✅ Improved SEO
✅ Better streaming capabilities
✅ Lower frontend complexity
✅ Easier debugging
✅ Reduced hydration costs
✅ Better performance on lower-end devices
✅ Simpler mental model
So What Do We Actually Get?
If HTMX and Declarative Partial Updates evolve together, we may end up with something surprisingly powerful.
1. SPA-Like User Experience Without SPA Complexity
Users get:
- Fast updates
- Smooth interactions
- Incremental rendering
- Responsive interfaces
Developers avoid:
- Massive hydration costs
- Excessive client-side state
- Complex frontend infrastructure
2. HTML Becomes The Transport Protocol Again
Instead of:
Data
↓
JSON
↓
Client Logic
↓
UI
We get:
UI
↓
HTML
↓
Browser
The server sends the experience directly.
3. Better Performance By Default
Instead of:
Wait For Everything
↓
Render
We get:
Render What Is Ready
↓
Render More
↓
Render More
Users see progress immediately.
4. Simpler Systems
Fewer layers.
Less synchronization.
Less duplicated rendering logic.
Less code.
5. A Better Fit For Streaming AI
AI is inherently streamed.
DPU treats streaming as a first-class experience.
That's a very interesting direction.
Let's Be Real: This Doesn't Replace Every Application
Whenever a new architectural pattern appears, the internet tends to split into two camps.
"This changes everything!"
and
"This is useless!"
The truth is usually somewhere in the middle.
Declarative Partial Updates are exciting.
But they are not a silver bullet.
Today they are still emerging browser capabilities.
They are not widely deployed across production environments.
They are not yet the default architecture for modern web applications.
And many applications genuinely benefit from rich client-side frameworks.
Think about:
- Figma
- Canva
- Google Docs
- Miro
- VS Code Web
- Complex trading platforms
- CAD applications
These systems maintain significant client-side state and interaction models.
They're unlikely to become primarily server-driven any time soon.
React, Vue, and other client-side frameworks will continue to be excellent solutions for those kinds of experiences.
The bigger opportunity lies elsewhere.
The vast majority of software is not Figma.
Most software is:
- Dashboards
- Admin portals
- Business applications
- Analytics systems
- Internal tools
- AI products
- Content-centric applications
For those applications, server-driven architectures are becoming increasingly attractive.
The exciting part isn't that DPU replaces existing solutions.
The exciting part is what it suggests about where the web platform is heading.
Final Thoughts
For years we've been moving more and more logic from servers into browsers.
Maybe the future isn't about moving even more.
Maybe it's about making HTML smarter.
HTMX demonstrated that HTML fragments can serve as an application protocol.
Declarative Partial Updates suggest HTML could also become a streaming protocol.
And if that vision succeeds, we may finally stop arguing about:
SPA vs SSR
Because the answer might become:
Server-driven UI with browser-native streaming.
The most interesting part isn't that HTMX gets more powerful.
The most interesting part is that the browser itself is evolving in a way that makes server-driven architectures feel modern again.
For years, we've been treating HTML as a document format and JavaScript as the application platform.
Declarative Partial Updates challenge that assumption.
What if HTML itself becomes capable of handling richer application workflows?
What if the browser can assemble interfaces incrementally without requiring massive client-side runtimes?
What if we can get SPA-like experiences while keeping the simplicity of server-rendered applications?
That's what makes this moment so interesting.
Not because HTMX wins.
Not because React loses.
But because the web platform itself is becoming more capable.
And for the first time in a long while, it feels like we're moving toward a future where developers don't have to choose between:
Simple Architecture
OR
Rich User Experience
We may finally be able to have both.
After years of increasing complexity, the web might be quietly coming full circle.
And honestly?
That's a future I'm excited to build for.
What do you think?
Are Declarative Partial Updates the missing primitive that could make server-driven UI mainstream again?
Or will React and other client-heavy architectures continue to dominate the next decade?
I'd love to hear your thoughts in the comments 👇
Top comments (0)