For many years, modern web development has been shaped by one major problem: how can a web page update only the part that changed instead of reloading the entire page?
This problem is the reason developers use JavaScript frameworks, client-side routing, hydration, virtual DOM systems, AJAX, HTMX, React Server Components, server-side streaming, and many other patterns. The goal is usually the same: keep the page fast, interactive, and up to date without forcing the browser to reload everything.
Declarative Partial Updates are a new web platform proposal that tries to bring part of this behavior directly into HTML. Instead of writing JavaScript to find an element and replace its content, the server can send a special piece of HTML that tells the browser which part of the document should be updated.
In simple words, Declarative Partial Updates allow the browser to receive HTML patches and apply them to existing parts of the page.
This is important because it could make server-rendered websites more powerful, reduce JavaScript dependency, improve streaming performance, and simplify how developers build dynamic pages.
Chrome’s developer documentation describes the idea as a way to stream new HTML templates into a page and dynamically update different parts of content without directly targeting each update through separate JavaScript DOM references.
What Are Declarative Partial Updates?
Declarative Partial Updates are a proposed HTML feature that allows a web page to update specific regions of the document using HTML itself.
The word declarative means the developer describes what should happen, not how to manually do it step by step.
For example, in traditional JavaScript, a developer might write:
document.querySelector("#profile").innerHTML = newProfileHTML;
That is an imperative instruction. It tells the browser exactly how to find the element and replace the content.
With Declarative Partial Updates, the server could instead send HTML that says:
<template for="profile">
<h2>Kawsar Ahmed Fahad</h2>
<p>Front-end Developer and Founder of Faha Studio</p>
</template>
The browser would understand that this template is meant to update a specific target named profile.
The WICG explainer describes this proposal as a way to introduce partial out-of-order HTML streaming as part of the web platform. It explains that patches are delivered using a <template> element with a for attribute that targets an existing part of the DOM.
Why This Matters
Today, partial page updates usually require JavaScript.
For example, when a user opens a dashboard, the page may load the main layout first and then separately load:
User profile data
Notifications
Analytics cards
Recent orders
Messages
Charts
Recommended content
In most modern applications, JavaScript handles those updates. The browser downloads scripts, executes them, fetches data, converts data into UI, and then updates the DOM.
This works, but it creates complexity.
Developers need to manage:
Declarative Partial Updates aim to simplify this by allowing the server to stream HTML directly into the right place.
That means the server can send the shell of the page first, then send different page sections later as they become ready.
A simple example would be:
<body>
<main>
<?start name="dashboard">
<p>Loading dashboard...</p>
<?end>
</main>
<template for="dashboard">
<section>
<h1>Dashboard Ready</h1>
<p>Your latest business data is now available.</p>
</section>
</template>
</body>
The browser first shows the loading content. When it receives the matching template, it replaces the target section with the real content.
The Core Problem: HTML Normally Streams Top to Bottom
HTML already supports streaming. A server does not need to generate a full page before sending it to the browser. It can send the top part of the document first, then continue sending more HTML as it becomes available.
This is powerful because users can start seeing the page before the entire response is complete.
However, traditional HTML streaming has one limitation: it is naturally top-to-bottom.
That means if the browser reaches a slow part of the page, it may block the rendering of content below it.
For example:
<header>Fast header</header>
<section>
Slow product recommendations from database
</section>
<footer>Fast footer</footer>
If the recommendations section is slow, the footer might not arrive quickly, even though the footer itself is simple.
Modern frameworks solve this using JavaScript-based streaming techniques. For example, React can stream content out of order by injecting scripts that update already-parsed parts of the DOM. The WICG explainer specifically notes that React streams out-of-order content by injecting inline script tags that modify the DOM.
Declarative Partial Updates try to make a similar idea possible natively through HTML.
How Declarative Partial Updates Work
The idea has two main parts:
A placeholder or target area in the HTML document.
A later HTML patch that updates that target.
The placeholder marks the area that can be replaced. The patch provides the new content.
The proposal uses processing instructions and templates to define this relationship.
A simplified structure looks like this:
<section>
<?start name="news-card">
<p>Loading latest news...</p>
<?end>
</section>
<template for="news-card">
<article>
<h2>Meta Expands Paid Subscriptions</h2>
<p>Meta is building new revenue models across Facebook, Instagram, WhatsApp and AI.</p>
</article>
</template>
Here is what happens:
The browser first sees the placeholder named news-card.
It displays the fallback content:
<p>Loading latest news...</p>
Later, when the browser receives:
<template for="news-card">
...
</template>
It replaces the placeholder with the content inside the template.
The result becomes:
<section>
<article>
<h2>Meta Expands Paid Subscriptions</h2>
<p>Meta is building new revenue models across Facebook, Instagram, WhatsApp and AI.</p>
</article>
</section>
No custom JavaScript is required for the replacement.
Understanding the Placeholder
The placeholder tells the browser where future content should go.
The proposal uses processing instructions like:
<?start name="profile">
Loading profile...
<?end>
The name identifies the target.
The matching patch later uses:
<template for="profile">
Updated profile content
</template>
The for value connects the patch to the placeholder.
The WICG explainer gives a similar example where a placeholder named gallery is replaced by actual gallery content from a later template. It also explains that the content between the start and end processing instructions is replaced by the patch.
Why Use <template>?
The <template> element is already part of HTML. Content inside a template is not rendered immediately as normal page content.
That makes it useful for holding update content before the browser applies it.
For Declarative Partial Updates, the template acts like a patch package.
Example:
<template for="cart-summary">
<div class="cart-summary">
<h2>Your Cart</h2>
<p>3 items</p>
<strong>Total: $59.00</strong>
</div>
</template>
This tells the browser:
“Take this HTML and apply it to the target named cart-summary.”
The benefit is that the server sends normal HTML, not JSON plus JavaScript rendering logic.
Out-of-Order Streaming
One of the most powerful parts of Declarative Partial Updates is out-of-order streaming.
Normally, the server sends HTML in document order. But real-world pages do not always become ready in order.
For example:
Header may be ready instantly.
User profile may take 200 milliseconds.
Analytics chart may take 2 seconds.
Recommendations may take 1 second.
Footer may be ready instantly.
Without out-of-order updates, the slow section can delay the full page experience.
With Declarative Partial Updates, the server can send the shell first:
<body>
<header>Faha Studio</header>
<main>
<?start name="profile-card">
<p>Loading profile...</p>
<?end>
<?start name="analytics">
<p>Loading analytics...</p>
<?end>
<?start name="recommendations">
<p>Loading recommendations...</p>
<?end>
</main>
<footer>© Faha Studio</footer>
</body>
Then the server can stream patches as each part becomes ready:
<template for="profile-card">
<section>
<h2>Kawsar Ahmed Fahad</h2>
<p>Founder, Faha Studio</p>
</section>
</template>
Then:
<template for="recommendations">
<section>
<h2>Recommended Articles</h2>
<ul>
<li>How AI Search Changes SEO</li>
<li>Why Businesses Need GEO Optimization</li>
</ul>
</section>
</template>
Then, later:
<template for="analytics">
<section>
<h2>Analytics</h2>
<p>Page views increased by 42% this week.</p>
</section>
</template>
The analytics section can arrive last without blocking the rest of the page.
This is the main advantage: different parts of the page can appear when they are ready.
A Simple Real-World Example: Newsroom Page
Imagine Faha Studio has a newsroom article page.
The article body loads fast, but related posts, author profile, and trending articles need separate database queries.
The initial page could look like this:
<article>
<h1>How Declarative Partial Updates Work in HTML</h1>
<p>Declarative Partial Updates allow specific parts of a page to be updated using HTML patches.</p>
</article>
<aside>
<?start name="author-box">
<p>Loading author...</p>
<?end>
<?start name="trending-news">
<p>Loading trending articles...</p>
<?end>
</aside>
Then the server sends:
<template for="author-box">
<div class="author-box">
<h2>Faha Studio Newsroom</h2>
<p>Covering technology, business, AI and digital transformation.</p>
</div>
</template>
And later:
<template for="trending-news">
<div class="trending-news">
<h2>Trending</h2>
<ul>
<li>Meta Paid Subscription Explained</li>
<li>How AI Search Is Changing Content Strategy</li>
<li>Why Small Businesses Need Fast Websites</li>
</ul>
</div>
</template>
The user gets the article immediately, while supporting content appears as soon as it is ready.
How It Differs from Traditional AJAX
Traditional AJAX usually works like this:
Browser loads the page.
JavaScript runs.
JavaScript sends a request to the server.
Server returns JSON or HTML.
JavaScript finds the target element.
JavaScript updates the DOM.
Example:
fetch("/api/trending")
.then(response => response.text())
.then(html => {
document.querySelector("#trending-news").innerHTML = html;
});
Declarative Partial Updates move the update behavior into HTML parsing.
Instead of JavaScript saying:
“Find this element and replace it.”
The HTML itself says:
“This patch belongs to this target.”
That reduces the need for client-side update code.
How It Differs from HTMX
HTMX is a popular JavaScript library that lets developers build dynamic pages using HTML attributes. It can request HTML from the server and swap parts of the page.
Example HTMX code:
<button hx-get="/profile" hx-target="#profile">
Load Profile
</button>
<div id="profile"></div>
HTMX is powerful because it makes HTML-driven interactivity easy.
Declarative Partial Updates are conceptually similar because they also treat HTML as the main response format. But the key difference is that HTMX is a JavaScript library, while Declarative Partial Updates are proposed as browser-level behavior.
Chrome’s developer article explains that HTMX is conceptually close because it requests HTML from the server and replaces page content, but HTMX still depends on JavaScript, while the goal of Declarative Partial Updates is to make some HTML patching behavior a browser feature.
How It Differs from React
React applications usually update the UI through component state.
For example:
function Profile() {
const [profile, setProfile] = useState(null);
useEffect(() => {
fetch("/api/profile")
.then(res => res.json())
.then(data => setProfile(data));
}, []);
if (!profile) return <p>Loading...</p>;
return <h2>{profile.name}</h2>;
}
React controls the rendering process through JavaScript.
Declarative Partial Updates work differently. The server can send rendered HTML directly, and the browser applies it as a patch.
React is still more powerful for complex application state, client-side interactions, and highly dynamic interfaces. Declarative Partial Updates are not a full React replacement. They are more focused on server-rendered partial HTML updates.
This could be especially useful for:
News websites
Blogs
Dashboards
E-commerce pages
Documentation sites
Admin panels
Search result pages
Comment sections
Server-rendered apps
How It Differs from Server-Side Rendering
Traditional server-side rendering generates the full HTML page on the server and sends it to the browser.
Example:
<html>
<body>
<h1>Product Page</h1>
<section>Product details</section>
<section>Reviews</section>
<section>Related products</section>
</body>
</html>
The server normally waits until all sections are ready.
Declarative Partial Updates allow the server to send a shell first and stream the slower sections later.
So instead of waiting for everything, the server can send:
<h1>Product Page</h1>
<?start name="reviews">
Loading reviews...
<?end>
<?start name="related-products">
Loading related products...
<?end>
Then it can send patches when ready.
This improves perceived performance because the user sees useful content sooner.
Declarative Partial Updates can improve performance in several ways.
First, the browser can show the page shell quickly. The user does not need to wait for every database query or API call to finish.
Second, less JavaScript may be needed. Smaller JavaScript bundles can improve loading speed, especially on slower devices and mobile networks.
Third, servers can stream independent sections as soon as they are ready. This can reduce blocking behavior in complex pages.
Fourth, the browser can handle patching natively instead of relying on framework-specific client-side logic.
This is especially important for content-heavy websites, marketplaces, SaaS dashboards and newsroom platforms.
For Faha Studio, this type of technology matters because modern websites are no longer judged only by design. They are judged by speed, interactivity, accessibility, SEO, and user experience.
SEO Benefits
Declarative Partial Updates may also support SEO-friendly development because the server still sends HTML.
Search engines generally understand server-rendered HTML better than heavily client-rendered pages. If important content is available as HTML rather than being fully generated after JavaScript execution, it may improve crawlability.
However, developers still need to be careful.
Important article content, product descriptions, metadata, canonical tags and structured data should not depend entirely on late patches. Critical SEO content should be available in the initial HTML whenever possible.
Good use cases for partial updates include:
Related articles
Recommended products
Comment previews
User-specific widgets
Sidebar cards
Trending content
Analytics panels
Notification blocks
Risky use cases include:
Main article body
Product title
Primary heading
Canonical metadata
Structured data
Essential navigation
For newsroom websites, the article itself should load in the initial response. Dynamic sidebars and secondary content can be streamed later.
AEO and GEO Benefits
AEO means Answer Engine Optimization. GEO means Generative Engine Optimization.
Both are becoming important because users increasingly discover content through AI search engines, answer engines, and generative assistants.
Declarative Partial Updates may help AEO and GEO indirectly by encouraging cleaner server-rendered HTML.
AI crawlers and answer engines often prefer clear page structure:
<h1>Main question</h1>
<p>Direct answer</p>
<h2>How it works</h2>
<p>Detailed explanation</p>
<h2>Examples</h2>
<p>Practical examples</p>
If the main content is delivered as clean HTML, it becomes easier for machines to understand.
For Faha Studio’s newsroom, this means every article should include:
A clear headline
A short summary
Direct answer sections
Definitions
Examples
FAQ blocks
Schema markup
Author information
Publication date
Updated date
Internal links
Declarative Partial Updates can support this model by keeping the main article readable while streaming additional modules like related content and recommendations.
Potential Use Cases
Declarative Partial Updates could be useful in many real-world products.
1. News Websites
A news website can render the article first and stream:
Trending articles
Author bio
Related news
Stock tickers
Live updates
Comment sections
2. E-commerce Websites
An online store can render product information first and stream:
3. SaaS Dashboards
A SaaS app can render the dashboard shell first and stream:
Analytics cards
Charts
Usage metrics
Billing status
Recent activity
Team notifications
A social platform can load the feed shell and stream:
User profile card
Suggested friends
Notifications
Comments
Reactions
An e-learning platform can render the lesson page first and stream:
Progress tracking
Quiz status
Recommended lessons
Discussion threads
Teacher notes
Example: Dashboard with Multiple Independent Sections
<main>
<h1>Business Dashboard</h1>
<section>
<?start name="sales-card">
<p>Loading sales data...</p>
<?end>
</section>
<section>
<?start name="orders-card">
<p>Loading order data...</p>
<?end>
</section>
<section>
<?start name="customer-card">
<p>Loading customer data...</p>
<?end>
</section>
</main>
Then the server streams patches:
<template for="orders-card">
<div class="card">
<h2>Orders</h2>
<p>128 new orders today</p>
</div>
</template>
<template for="sales-card">
<div class="card">
<h2>Sales</h2>
<p>৳245,000 revenue this week</p>
</div>
</template>
<template for="customer-card">
<div class="card">
<h2>Customers</h2>
<p>42 new customers joined today</p>
</div>
</template>
The order of arrival does not need to match the order of the page.
That is the power of out-of-order streaming.
Current Status of Declarative Partial Updates
Declarative Partial Updates are still a developing web platform proposal, not a fully universal HTML feature available everywhere.
The WICG repository describes the proposal and explains the concept of declarative patching. Chrome’s developer blog has also discussed how streaming <template for> elements into HTML can update different parts of the page.
Chrome Platform Status lists Declarative Document Patching as a feature related to streaming HTML content out of order and updating an existing document with encoded patches.
Because this is still experimental, production websites should not depend on it without progressive enhancement, fallbacks or framework support.
Limitations and Concerns
Declarative Partial Updates are promising, but they are not a complete solution for every web application.
1. Browser Support Is Not Universal Yet
Because the feature is still experimental, developers cannot assume all browsers support it.
2. It Does Not Replace JavaScript
JavaScript will still be needed for:
Complex interactions
Client-side state
Form validation
Animations
Offline behavior
Drag-and-drop
Real-time collaboration
Rich web applications
3. Security Must Be Handled Carefully
Any system that inserts HTML into a page must be careful about cross-site scripting.
Server-generated HTML must be sanitized, escaped and trusted.
4. State Management Is Still a Challenge
Declarative Partial Updates can update HTML, but they do not automatically solve complex application state problems.
Frameworks, debugging tools, testing libraries and deployment platforms need time to adopt this pattern.
Security Considerations
If a server streams HTML patches into a page, developers must treat those patches with the same security discipline as any other HTML output.
Important rules include:
Escape user-generated content.
Do not inject raw untrusted HTML.
Use strict Content Security Policy.
Validate server-side data.
Avoid exposing sensitive information in streamed patches.
Protect authenticated patch endpoints.
Ensure user-specific content is not cached publicly.
Audit templates for XSS risks.
For example, unsafe code like this should be avoided:
<template for="comment-section">
<p>User comment: <script>alert("XSS")</script></p>
</template>
Instead, user content should be safely escaped:
<template for="comment-section">
<p>User comment: <script>alert("XSS")</script></p>
</template>
Security is especially important for dashboards, admin panels, e-commerce platforms and authenticated user areas.
How This Could Affect Frameworks
Declarative Partial Updates may influence how future frameworks handle server rendering and streaming.
Frameworks like Next.js, Astro, Remix, Laravel, Rails, Django and others already care about server-rendered HTML and partial updates.
If the browser can handle some patching natively, frameworks may use this feature behind the scenes.
Possible future framework behavior:
<Suspense fallback={<Loading />}>
<UserProfile />
</Suspense>
Instead of sending JavaScript patches, a framework could stream native HTML patches when supported.
This would make server-first applications more efficient.
Astro’s island architecture is also relevant here. Chrome’s developer article notes that island-based rendering is one use case because independent regions of a page can be rendered at different times.
Why Developers Should Care
Declarative Partial Updates matter because they represent a larger direction for the web.
The web platform is moving toward:
For developers, this means HTML is becoming more capable again.
For businesses, this means websites can become faster and more cost-efficient.
For users, this means pages can load sooner and feel smoother.
Practical Advice for Developers
Developers should not rush to rebuild production systems around Declarative Partial Updates yet. But they should understand the concept because it may shape future web development patterns.
Recommended approach:
Start by learning server-side streaming.
Use progressive enhancement.
Keep critical content in the initial HTML.
Use JavaScript where it adds real value.
Avoid sending large JavaScript bundles just for simple content replacement.
Follow browser support updates.
Experiment in non-critical projects.
For current production use, developers can explore similar patterns with:
Declarative Partial Updates may eventually make some of these patterns simpler and more native.
Conclusion
Declarative Partial Updates are an important step toward making HTML more dynamic without forcing developers to rely on heavy JavaScript for every partial page update.
The idea is simple but powerful: mark a part of the page, then stream a matching HTML patch that updates it.
This allows pages to load faster, stream content out of order, reduce client-side complexity and make server-rendered apps more flexible.
It will not replace JavaScript frameworks completely. It will not solve every state management problem. It is also not yet a universal browser feature. But it shows where the web is heading: toward a more capable, server-friendly, HTML-first future.
For Faha Studio and modern web teams, Declarative Partial Updates are worth watching closely. They could become one of the most important browser-level improvements for building faster, cleaner and more scalable web experiences.
FAQ
What are Declarative Partial Updates in HTML?
Declarative Partial Updates are a proposed HTML feature that allows specific parts of a web page to be updated using streamed HTML patches instead of custom JavaScript DOM manipulation.
Are Declarative Partial Updates available in all browsers?
No. The feature is still experimental and should not be treated as universally available in production.
Do Declarative Partial Updates replace JavaScript?
No. They reduce the need for JavaScript in some partial update cases, but JavaScript is still needed for complex interactivity and client-side state.
Are Declarative Partial Updates similar to HTMX?
Yes, conceptually. Both focus on HTML-based updates. But HTMX is a JavaScript library, while Declarative Partial Updates are proposed as native browser behavior.
Why are Declarative Partial Updates important?
They could make server-rendered websites faster, simpler and more efficient by allowing HTML sections to update independently as they become ready.
Can this help SEO?
It can help indirectly if the website keeps important content in clean server-rendered HTML. However, critical SEO content should still be included in the initial page response whenever possible.
