What if Joomla could update only what changed, instead of reloading the entire page?

Declarative Partial Updates make that possible.

Today, many interactions in Joomla’s administrator interface follow a familiar pattern. An administrator publishes an article, changes a filter or moves to another page of results. The browser submits the form, Joomla processes the request and the complete page reloads.

This workflow is reliable, but often unnecessary. In many cases, only the content area, toolbar or system messages need to change.

As part of the Ajaxified Backend project in Joomla Academy 2026, we are using Declarative Partial Updates, or DPU, to handle these interactions more efficiently.

The goal is simple: make Joomla more responsive while preserving its server rendered architecture.

What Are Declarative Partial Updates?

Declarative Partial Updates are a set of emerging web platform APIs being developed to make HTML updates more flexible.

The proposal has two related parts:

1. out-of-order updates using processing instructions and <template>  elements;

2. new JavaScript APIs for inserting and streaming HTML into an existing document.

The first part allows HTML to mark a region that can be updated later.

For example:

<div>

    <?start name="article-list"?>

        <!-- Current article list -->

    <?end?>

</div>

New content for that region can then be provided using a template:

<template for="article-list">

    <!-- Updated article list -->

</template>

When the template is processed, the browser finds the matching named region and replaces its contents.

This is different from a conventional JavaScript update. JavaScript does not need to locate the target element and manually rebuild its DOM structure. The HTML itself declares where the new content belongs.

The second part of DPU introduces a consistent family of static and streaming HTML insertion methods. These include operations for replacing, appending, prepending or inserting HTML around an existing element.

For a detailed explanation, examples and demonstrations, see Declarative partial updates on Chrome for Developers.

Why DPU Fits Joomla

Joomla already has a mature server side rendering architecture.

Its controllers process requests, models manage data, layouts produce HTML, access rules control permissions and plugins respond to application events. The server also determines how toolbars, forms, messages and list views should appear for the current user.

Recreating this knowledge in JavaScript would introduce a second rendering layer that would need to remain synchronised with the PHP application.

DPU offers a more natural approach:

• Joomla continues rendering the authoritative interface on the server.
• Existing permissions, validation and plugin events continue to run.
• JavaScript coordinates the request and applies the returned HTML.
• Only the regions that changed are updated in the current document.

This allows Joomla to improve responsiveness without changing where its business rules and rendering decisions belong.

The server remains responsible for the result. DPU changes how that result reaches the page.

How Jooola Is Using an Emerging Web Standard

When an eligible administrator action is triggered, Joomla follows this process:

1. The existing administrator form is submitted asynchronously.
2. The request passes through Joomla’s normal controller and model.
3. Permissions, validation and plugin events run as usual.
4. Joomla renders the updated page on the server.
5. The client parses the response and extracts the regions that changed.
6. Those regions are converted into <template for> patches.
7. The patches are inserted into the live document and applied to the matching DPU boundaries.

Joomla currently prepares these patches after receiving the complete server response. It uses the proposed streaming insertion APIs to apply the templates, but it does not yet progressively display the response while it is being downloaded.

The process remains server driven. Only the way the resulting HTML is applied has changed.

An Experimental But Practical Technology

DPU is still under development.

The APIs are available for developer testing from Chrome 148 onward behind the experimental web platform features flag. They are not yet enabled by default or supported natively across all major browsers.

Polyfills are available for common use cases, but they cannot reproduce every capability. In particular, the HTML insertion polyfill buffers content before applying it rather than providing true streaming.

The proposed insertion APIs include safe and unsafe variants:

• Safe methods use a sanitizer by default.
• Unsafe methods disable automatic sanitisation.
• The optional script execution setting defaults to false.

Joomla currently uses streamAppendHTMLUnsafe( ) with script execution explicitly disabled. The inserted patches are derived from Joomla’s own server rendered response.

Applying DPU in Joomla goes far beyond a small demonstration. The implementation must work with:

• security controls;
• Web Components;
• scripts and styles;
• third party extensions;
• complex forms;
• long lived administrator interfaces.

This places Joomla among the earliest major open source CMS projects publicly using DPU in a real world administrative interface.

Progressive Enhancement Remains Important

Not every administrator action is handled through DPU.

A server defined policy determines which submissions are eligible for partial updates. Actions that should leave the current workspace, or are not explicitly supported, continue through Joomla’s normal form submission behaviour.

Because native DPU support remains experimental, reliable feature detection or a suitable polyfill will also be required before the enhancement can be enabled across unsupported browsers.

The principle remains important: DPU should enhance Joomla’s established workflows, not become their only path.

What DPU Could Mean for Joomla

DPU offers Joomla a more responsive administrator experience without changing the foundations it already relies on.

Joomla can continue rendering the correct interface on the server while updating only the regions that have changed. This avoids duplicating application logic in a separate client side rendering layer.

The technology is still evolving, but testing it now gives Joomla valuable experience with an important new direction for the web platform.

The aim is not to replace Joomla’s server rendered architecture.

It is to strengthen that architecture with browser native partial updates.