Vapor Mode发布前，你应该知道的一些事情！

前端从进阶到入院 · 公众号 · · 2025-01-20 08:00

正文

Vue3 的 Vapor Mode 概念不知不觉已经提出来一年了，可以说是吊足了 coder 们的胃口，我去年的一篇莫名其妙成为爆款的文章 🎉尤雨溪为什么要推出Vapor Mode🎉 中，我直观的展示了细粒度更新 dom 的优点，让大家历历在目！

新的消息，2025 年 1 月 29 日至 30 日，将会举办 Vue.js Nation Conference ，详情你可以看这里：https://vuejsnation.com/

会议议题最值得关注的有两个：

十分期待这次的会议，不过在了解 vapor mode 功能前。我们可以先了解下它解决了哪些问题。

众所周知， vue 的 view 模块被设计成以 template 对应的 render 函数为最小单元更新视图（也就是以组件为粒度更新），

所以在一些极端场景下，例如页面中有大量动态更新的节点时， diff 计算仍然可能造成性能瓶颈，因为仍然会有不必要的 dom 渲染。

所以 vapor mode 的首要目标是解决各种场景的性能瓶颈。最好的方案是跳过虚拟 dom ，直接绑定数据到具体的 dom 节点，实现细粒度更新。

目前（虚拟 dom 版本）这么设计的原因并非无法实现以最小 dom 为粒度更新视图，而是以组件更新，可以较少复杂的 diff 计算。

vapor mode 让 vue 成为细粒度更新的框架，必然需要打破这一行为（放弃基于虚拟 dom 更新）！

目前所有的框架中，已经实现的将数据和具体 dom 节点绑定的框架有： svelte 5 、 solidjs 、 angular 16 。

而这些框架的无独有偶选择拥抱了 siganl 系统实现了数据和具体 dom 的绑定！

我们可以预见： vue 在 3.x 大版本中，是不会放弃基于 proxy 的 reactivity 响应式系统的，

如果 vapor mode 在 3.x 大版本中发布，我们将会看到基于 reactivity 系统的数据和具体 dom 的绑定的方案。

还有一个问题，我们以前提到， vue 虽然不像 react 一样重运行时，但是他的运行时，相对于 signal 系统的方案，还是偏长，

这是因为 vue 的响应式系统虽然精准，但依赖追踪是在 运行时 动态绑定的，复杂应用中会出现过多的无用依赖，导致性能下降。

所以 vapor dode 将会引入静态依赖绑定，在 编译阶段 确定数据与副作用之间的关系，避免运行时依赖追踪的开销。

我们知道，服务器端渲染（SSR）功能是现代前端框架的重要特性，目前该功能的统一流程是：服务端渲染 SSR 生成静态的 html 片段，然后客户端 Hydration 激活，生成动态内容和事件绑定，

在激活时，先要进行一次服务端的静态 html 和客户端的虚拟 dom 对比，如果两者不一致， Hydration 会丢弃服务端的 HTML ，重新生成客户端的 DOM ，这部分也会消耗性能，所以仍存在性能优化空间。

前面说过 vapor dode 将会引入静态依赖绑定，这样的话在理论上不需要 html