HTML’s Biggest Update in a Decade: Declarative Partial Updates

HTML’s Biggest Update in a Decade: Declarative Partial Updates Are Here

A new browser proposal lets servers stream HTML patches directly into the page — no JavaScript fetch calls, no DOM queries, no framework needed. Here’s what’s real, what’s ready, and what’s still experimental.

For years, displaying server-driven content on a web page has followed a ritual: download the HTML shell, download JavaScript, call fetch(), receive the data, find the right DOM node, inject the content. Every time. Even when the data was already sitting on the server.

That is the problem Declarative Partial Updates aims to solve — and for the first time, there is a real, working implementation in a major browser to prove it.

What the proposal actually does

The core idea is straightforward. Instead of sending JavaScript to reach back out to a server and patch the DOM, the server streams HTML patches directly into the document as part of the same HTTP response. The browser handles the swap. No script required.

You define a named placeholder using processing instructions in your HTML shell. The current proposal uses a <?start> / <?end> pair to wrap fallback content:

<section>
  <h2>Latest Posts</h2>
  <?start name="posts">
    <p>Loading...</p>
  <?end>
</section>

When the server is ready, it streams a <template for="posts"> element into the same response. The browser finds the matching placeholder and replaces the fallback content automatically:

<template for="posts">
  <article>How to Stream HTML Natively</article>
  <article>Declarative Shadow DOM Explained</article>
</template>

No fetch(). No getElementById. No innerHTML.

Out-of-order streaming: the most compelling part

What makes this genuinely exciting is that patches do not have to arrive in document order. A page can define multiple named placeholders for different sections — say, a user profile and a list of recommendations — and the server can stream whichever one is ready first.

If your profile query finishes in 80ms but your recommendations query takes 400ms, the profile patch streams in immediately. The recommendations follow when they are ready. Users see content fill in progressively rather than staring at a blank page waiting for the slowest query to finish.

The Chrome team describes the underlying goal as reducing the need to wait for the whole page to be ready, or to use a heavy JavaScript framework to deliver components asynchronously — two patterns that are common precisely because HTML has never had a native way to do this.

Current status: experimental, Chrome-only

The proposal has a published explainer in the WICG repository, an active pull request against the WHATWG HTML specification, and a real implementation path inside the Chromium project. As of late May 2026, the Chrome team has formally announced it as ready for developer testing.

However, Firefox and Safari have not yet signaled positions on the proposal. Cross-browser standardization — the step that would make this safe to depend on in production — is still ahead.

What you can use today: Declarative Shadow DOM

While Declarative Partial Updates is still experimental, its companion feature — Declarative Shadow DOM — became cross-browser baseline in August 2024, when Firefox 125 shipped support to match Chrome and Safari. It is safe to use in production right now.

Previously, attaching a Shadow Root to a custom element required JavaScript. With Declarative Shadow DOM, you can define the shadow tree in pure HTML:

<user-card>
  <template shadowrootmode="open">
    <style>
      .name { font-weight: bold; font-size: 1.2rem; }
    </style>
    <div class="name"><slot name="name"></slot></div>
    <div class="role"><slot name="role"></slot></div>
  </template>
  <span slot="name">John Doe</span>
  <span slot="role">Software Engineer</span>
</user-card>

The browser parses and renders this directly — no hydration step, no client-side bundle. It just works in every major browser today.

Why this matters beyond React and Astro

Modern frameworks have each found clever ways around HTML’s limitations. React’s streaming SSR patches the DOM using inline <script> tags. Astro’s island architecture hydrates components independently. htmx swaps HTML fragments with lightweight JavaScript.

All of these approaches are genuinely useful — and all of them are workarounds. They are doing something the browser itself should have been able to do natively. Declarative Partial Updates asks a more direct question: what if HTML could handle this without any runtime at all?

If the proposal achieves cross-browser adoption, the answer to “how do I show dynamic server content without a heavy JavaScript framework?” would become: you stream HTML, and the browser handles it. Full stop.

That era is not here yet. But for the first time, a working implementation is. Developers can test it in Chrome today, and the standardization process is moving. The next step is signals from Firefox and Safari — and that is where the real story will be told.