引言：Joomla 后台的一次悄然革命
如果你在 2026 年夏天打开 Joomla 社区杂志的 7 月刊，你会发现一篇技术文章可能正在悄悄改变 Joomla 管理后台的未来。7月20日，Joomla Academy 2026 的参与者 Adarsh Dubey 发表了《Beyond Full Page Reloads: How Joomla Is Using Declarative Partial Updates》一文，详细阐述了 Joomla 如何引入一项全新的 Web 平台标准——声明式局部更新（Declarative Partial Updates，简称 DPU），让管理后台的操作不必每次都触发整页刷新。
这篇文章的重要性在于：它不是某个第三方扩展的炫技，而是Joomla 核心架构的一次进化。在 WordPress 的 Gutenberg 以 React + 块编辑器重塑后台体验、Drupal 用现代 JS 框架重构管理界面的背景下，Joomla 选择了一条截然不同的技术路线——不重建前端，而是通过浏览器原生能力增强现有架构。这个决策背后，是对 CMS 本质的深刻理解。
什么是声明式局部更新（DPU）？
DPU 是一套仍在制定中的 Web 平台 API，核心思想非常简单：用 HTML 标记来声明哪些页面区域可以被替换，然后让浏览器自动匹配新内容到对应区域。
它在 HTML 中使用两种关键机制：
1. 处理指令标记区域
通过在 HTML 中使用 <?start name="区域名称"?> 和 <?end?> 来定义可替换区域：
<div>
<?start name="article-list"?>
<!-- 当前文章列表 -->
<?end?>
</div>2. Template 补丁替换
当需要更新时，服务端返回一个带 for 属性的 <template> 标签，浏览器会自动找到匹配的命名区域并替换其内容：
<template for="article-list">
<!-- 更新后的文章列表 -->
</template>整个过程不需要任何 JavaScript 手动定位 DOM 和重建结构。浏览器原生就能理解"我要更新哪个区域、用这份 HTML 替换它"。这是一种完全声明式的局部更新模型。
此外，DPU 还提供了一套新的 JavaScript API，支持将 HTML 以流式写入现有文档，包括替换、追加、前置、围绕元素插入等多种操作方式。
为什么 Joomla 选择 DPU 而不是 React/Vue？
这是整篇文章最精彩的部分，也是 Adarsh 对 Joomla 架构理解最到位的地方。
Joomla 的架构是典型的三层 MVC：控制器处理请求、模型管理数据、布局生成 HTML。权限校验、插件事件、数据验证全部在服务端完成。如果强行引入 React 或 Vue 等前端框架，会发生什么？
你会被迫维护两套渲染逻辑：一套在 PHP 服务端（已有），一套在 JavaScript 客户端（新引入）。这意味着权限需要在前端再实现一遍，插件钩子需要在前端再对接一遍，数据验证逻辑需要在两端保持同步。对一个已经稳定运行近二十年的 CMS 来说，这不仅成本极高，而且风险巨大。
DPU 的优雅之处在于：
- Joomla 继续在服务端渲染完整页面
- 权限、验证、插件事件全部照常运行
- JavaScript 只做一件事：异步提交请求并应用返回的 HTML
- 服务端仍然决定最终渲染结果，DPU 只改变了结果如何到达页面的方式
换句话说，DPU 让 Joomla 在提升用户体验的同时，没有动摇服务端渲染的根基。这是对 James Mickens 那句名言——"服务端渲染不是架构缺陷，而是一种选择"——的最佳实践。
Joomla 的 DPU 实现流程
当管理员在后台触发一个支持局部更新的操作时，实际流程是这样的：
- 表单通过异步方式提交
- 请求经过 Joomla 常规的控制器 → 模型 → 权限校验 → 验证 → 插件事件
- 服务端渲染更新后的完整页面（不是部分 JSON 数据）
- 客户端解析响应，提取出哪些区域发生了变化
- 将变化区域转换为
<template for="...">补丁 - 补丁被插入当前文档，自动应用到对应的 DPU 边界区域
值得注意的是，Joomla 目前是在收到完整服务端响应后才准备补丁，尚未实现边接收边显示的真正流式渲染。但即使是这个阶段，带来的体验提升已经非常明显——不再有整页白屏闪烁，不再丢失滚动位置，操作更加流畅。
实验性但方向正确
DPU 目前仍处于实验阶段：
- Chrome 148+ 可通过
chrome://flags开启"实验性 Web 平台特性"来测试 - 其他主流浏览器尚未原生支持
- 对不支持的浏览器需要使用 Polyfill 垫片
但这不影响它的战略意义。Joomla 成为最早一批在真实管理界面中公开使用 DPU 的主流开源 CMS 项目之一。这不是追逐时髦，而是在为未来 Web 平台的能力演进抢占先机。
文章还特别强调了渐进增强原则：并非所有操作都会走 DPU。服务端维护一个策略来决定哪些提交有资格被局部更新。应当离开当前工作空间的操作、未明确支持的操作，仍然沿用传统的完整表单提交流程。DPU 应当增强 Joomla 既有工作流，而不是成为唯一路径。
对中国 Joomla 开发者的启示
作为中国的 Joomla 开发者，我认为这条技术路线有几个值得关注的点：
1. 不要盲目追求"全 React 化"
WordPress 的 Gutenberg 路线看起来很美，但 Joomla 的 DPU 路线在工程上更加务实。如果你的 Joomla 网站主要是内容管理，服务端渲染 + DPU 可以让你在几乎不改动现有架构的情况下，获得接近 SPA 的操作体验。
2. 关注 Web 平台原生能力
DPU 不是 Joomla 发明的，而是 W3C 的 Web 标准提案。这意味着未来所有浏览器都可能原生支持这一能力。Joomla 团队提早尝试验证，为社区积累了宝贵经验。
3. 扩展开发者需要考虑兼容性
如果你的扩展有自己的 JavaScript 交互逻辑，未来需要考虑与 DPU 局部更新的协同。当页面区域被动态替换时，你是否需要重新绑定事件？如何保持状态？这些是值得提前思考的问题。
4. 中文社区的跟进机会
过去中文 Joomla 社区多是"使用者"而非"贡献者"。但 DPU 这样的新技术方向，意味着前方还没有成熟的最佳实践，每个人都有机会参与探索和贡献。希望有更多中文开发者加入到这个讨论中来。
总结
Adarsh 的文章最后总结得很好：目标不是替代 Joomla 的服务端渲染架构，而是通过浏览器原生的局部更新能力来加强它。Joomla 不是要变成一个单页应用，而是要成为一个响应更加灵敏、体验更加流畅的传统 CMS。
在 AI 重塑一切的时代，Joomla 选择了一条回归 Web 本质的技术路线——让浏览器做浏览器擅长的事（增量渲染），让服务端做服务端擅长的事（业务逻辑和权限控制）。这种克制和务实，恰恰是成熟开源项目的魅力所在。
对于中国的 Joomla 用户来说，可以期待在未来的 Joomla 6.x 版本中逐步体验到这种后台交互的改进。而我们能做的，是在这个过程中保持关注、参与讨论，并把好的实践带到中文社区来。
评论 (0)