假如 Web 当初不支持动态化

发布时间：2025-11-05 00:59:47 来源：云智核 作者：应用开发

本文转载自微信公众号「前端向后」，当初作者黯羽轻扬。不支转载本文请联系前端向后公众号。持动   

 楔子

Web 生而具有极其灵活的态化动态化基础能力，诸如：

一直以来的持动探索和实践似乎只是在不断地发掘动态化能力的工程价值，为其寻找更合适的态化应用场景，比如早期的当初frameset，如今的不支微前端/微应用

而移动端正好相反，生而具有许多灵活性限制：

移动业务的当初发展不断地对动态化能力提出更高的要求，但苦于缺少动态化的不支基础能力，所以一直在探索更灵活的持动技术方案，像早期的热修复/热更新，到如今的小程序

实际上，二者在动态化技术能力上所要解决的工程问题是免费源码下载一致的，比如动态加载依赖库、视图组件、甚至整个应用。所以不妨开个脑洞，假定 Web 不支持动态化，以 Native 的业务诉求来推演 Web 动态化技术的发展轨迹

伊始：原生 WebAssembly

从前，Web 应用程序只能被打包成这种wasm的二进制格式，发布到各大浏览器应用商店。期间，不仅要等待数天的审核，通过之后还要等用户主动安装更新，等到新版本真正“生效”(覆盖大多数用户)，可能已经是数月之后了

版本更迭慢，无论是战略性的重要功能还是十万火急的问题修复，都无法及时触达用户。即便线上着火了，最快速的救火方案也要几天甚至几周之后才能起到作用

为了能够更快地修复问题、降低风险，热修复方案的探索就此展开

浪花：为热修复引入脚本语言 JavaScript

热修复意味着要加载并运行(安装包之外的)逻辑代码，b2b供应网所以有人直接从 WebAssembly 模块加载机制入手，研究出了一些 Hook 方案，能够动态地换掉某些模块/文件

也有人沿着这个方向走得更远，权衡时效性、性能、兼容性与稳定性，通过编译插桩、工程配套设施、运行时框架等手段解决了模块依赖、版本管理、差量更新等问题，将应用程序的各个功能模块插件化

还有人另辟蹊径，引入轻量级的脚本语言运行时(如 JavaScript 引擎)，并在浏览器原生 WebAssembly 与 JavaScript 世界之间架起一座桥梁，允许通过 JavaScript 调用原生的系统平台能力，从而扩展出了动态化的基础能力

动态化漾起了一道波纹，紧接着是呼啸而来的动态更新浪潮

海啸：基于 JavaScript 的动态更新

往动态化方向迈出第一步之后，离全面动态化的大好前景也就一步之遥了：

Any application that can be written in JavaScript, will eventually be written in JavaScript. —— Jeff Atwood

(摘自The Principle of Least Power)

全面动态化意味着要：

从而实现以功能模块为单位的快速迭代，相当于将热修复技术应用到问题修复之外的需求迭代上，香港云服务器既不用发版，免去了审核周期，也不需要等待用户主动安装，新功能得以动态发布并迅速覆盖到活跃用户

堤坝：容器概念形成

随着动态化程度的不断提升，JavaScript 在应用程序中的占比越来越高，最终仅剩余无法动态化(或没有必要动态化)的部分仍由 WebAssembly 实现，包括：

这些部分形成了容器(原生外壳)，相当于运行在浏览器中的一个动态化运行时，在容器圈定的能力范围内，业务能够充分利用动态优势，实现快速修复、快速发布、快速触达、快速迭代

但随容器概念一同出现的，除了赋能业务跑得更快之外，还有动态业务与容器之间的依赖问题：

通过工程配套设施将依赖管束起来之后，接下来的首要问题是想办法保证动态业务所依赖的底层容器的可靠性

边界：HTML、JavaScript、CSS 构成容器标准

隔离变化的惯用手段是加一层抽象，将变化的部分置于抽象层之下：

抽象出的这些标准确立了稳固的容器边界，边界之内，动态业务能够肆意发挥，边界之下，容器同样能够不断精进、丰富容器能力，将边界拓宽。同时，具有标准定义的 API 能够以结构化的形式维护起来，对于开发体验大有裨益

云海：浏览器支持加载网络资源

另一方面，在标准化的过程中，一些动态化业务实践也沉淀到了容器之中，例如：

虽然从热修复开始就能够从CDN拉取 JS 文件，运行时动态解释执行了，但容器标准不仅对这种方式提供了便捷支持，还将动态化的基础能力从逻辑扩大到了视图、样式、静态资源等等

至此，动态化最关键的基础能力已经完备了。迁至 JavaScript 的功能模块甚至能够进一步部署到云端，实现离线集成、在线托管两种模式的灵活切换

一色：同步、异步模式切换自如

完备的动态化基础能力解锁了许多新玩法，例如：

将业务模块(bundle)进一步拆分成功能模块(chunk)，并将非核心模块异步出去，实现动态按需加载，例如第三方 JS SDK、jQuery 插件、以及分享/评论/城市选择等重磅组件

对于内容呈现的偏静态场景，还可以通过 SSR 在服务端完成(大部分)页面渲染工作，加快首屏内容展现

另一方面，Hydration、lazy 组件、Suspense 等运行时特性使得在线的动态部分能够与离线的非动态部分充分融合，实现更细粒度的业务动态化，让在线托管真正成为一种部署选项

与此同时，动态业务自身的组件化程度也在不断加深，前端开发的核心工作从页面、模块开发转向了组件、编排逻辑开发

流云：数据驱动的前端应用程序

组件体系趋向成熟之后，一个由来已久的概念终于彻底浮出水面——数据驱动

从前后端分层的数据协议，逐渐演变成数据驱动，这里的数据包括 3 部分：

将这些数据填入业务组件，即可渲染出完整的功能模块(无论是在客户端还是服务端)，再将其放置到视图容器中合适的坑位里，就完成了一次组件级的“发布”过程

这种模式涉及 5 个重要环节：

其中，业务组件、坑位是进一步动态化的关键，可分为 4 个阶段：

要达到多个萝卜到处扔的组件级动态化终极目标，就要求能够动态发布业务组件、动态发布坑位

交融：动态业务组件 + 动态坑位

从端和云的视角来看，业务组件也可以看作数据(云)的一部分，相比之下坑位与端的关联更为紧密，而动态化的唯一手段就是将端侧的东西搬到云上去，所以要解决的关键问题是如何实现坑位的动态化

有 2 个思路：

对于除页面之外的其它布局容器，如对话框、消息条、Banner 位、腰封等等，可以将坑位标准化成容器组件，与业务组件一并动态发布，将坑位的租赁关系维护在服务端，作为数据驱动的数据之一

至此，前后端分层的界限几经重新定义，终于迎来了 JSP/PHP 融合数据与模板的黄金年代……

原文链接：https://mp.weixin.qq.com/s/MssledyYt_2gqZ5Q7xgjFg

相关文章