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

前言

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

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

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

• vue3.6 功能预览
• vapor mode 的最新进展

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

Vapor Mode 将会解决的一些问题

💎 重复的dom渲染

众所周知，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性能与客户端Hydration激活

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

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

前面说过vapor dode将会引入静态依赖绑定，这样的话在理论上不需要html和客户端的虚拟dom的对比了。

最后

如果vapor mode如上所说，放弃了基于dom的更新方案，尽管性能得到了提升，但是也会面临新的挑战：

首先，开发者需要理解信号系统的基本原理，习惯以细粒度更新方式思考组件的概念了。

其次，另外vapor mode的引入可能使现有的vue工具链（如 Vue DevTools、插件生态）发生翻天覆地的变化。

另外，vue的vapor mode可能会和angular一样，同时保留旧的虚拟DOM渲染模式和新的细粒度渲染模式，

所以，希望每个开发者可以在特定场景中选择性的使用Vapor Mode，无需大规模重构现有项目，从而实现性能和开发体验的最佳平衡！

无论如何，vapor mode的发布将会推动前端框架在高性能和易用性之间找到新的平衡点，让我们拭目以待吧！！！

如果文章中，存在纰漏，欢迎指正！