相信大家都跟我一样有这样一个疑问：之前都说虚拟DOM是为了性能，怎么现在又反向宣传了？无虚拟DOM怎么又逆流而上成为了性能的标杆了呢？
下篇文章我们会仔细分析无虚拟DOM与虚拟DOM之间的区别，本篇文章我们先看数据。首先是体积，由于没有了虚拟DOM以及vDOM diff算法，所以体积肯定能小不少。当然不是说无虚拟DOM就彻底不需要diff算法了，我看过同为无虚拟DOM框架的Svelte和Solid源码，无虚拟DOM只是不需要vDOM间的Diff算法，列表之间还是需要diff的。毕竟再怎么编译，你从后端获取到的数组，编译器也不可能预测得到。
那么官方给出的数据是：
虽然没有想象中的那么多，但33.6%也算是小不少了。当然这个数据指的是纯Vapor模式，如果你把虚拟DOM和Vapor混着用的话，体积不仅不会减小反而还会增加。毕竟会同时加载Vapor模式的runtime和虚拟DOM模式的runtime，二者一相加就大了。
Vapor模式指的就是无虚拟DOM模式，如果你不太清楚二者之间有何关联的话，可以看一眼这篇：《无虚拟DOM版Vue为什么叫Vapor》
那性能呢？很多人对体积其实并不敏感，觉得多10K少10k都无所谓，毕竟现在都是5G时代了。所以我们就来看一眼官方公布的性能数据：
从左到右依次为：
- 原生
JS：1.01 Solid：1.09Svelte：1.11- 无虚拟
DOM版Vue：1.24 - 虚拟
DOM版Vue：1.32 React：1.55
数字越小代表性能越高，但无论再怎么高都不可能高的过手动优化过的原生JS，毕竟无论什么框架最终打包编译出来的还是JS。不过框架的性能其实已经挺接近原生的了，尤其是以无虚拟DOM著称的Solid和Svelte。但无虚拟DOM版Vue和虚拟DOM版Vue之间并没有拉开什么很大的差距，1.24和1.32这两个数字证明了其实二者的性能差距并不明显，这又是怎么一回事呢？
一个原因是Vue3本来就做了许多编译优化，包括但不限于静态提升、大段静态片段将采用innerHTML渲染、编译时打标记以帮助虚拟DOM走捷径等... 由于本来的性能就已经不错了，所以可提升的空间自然也没多少。
看完上述原因肯定有人会说：可提升的空间没多少可以理解，那为什么还比同为无虚拟DOM的Solid和Svelte差那么多？如果Vapor和Solid性能差不多的话，那可提升空间小倒是说得过去。但要是像现在这样差的还挺多的话，那这个理由是不是就有点站不住脚了？之所以会出现这样的情况是因为Vue Vapor的作者在性能优化和快速实现之间选择了后者，毕竟尤雨溪第一次公布要开始做无虚拟DOM版Vue的时间是在2020年：
而如今已经是2025年了。也就是说如果一个大一新生第一次满心欢喜的听到无虚拟DOM版Vue的消息后，那么他现在大概率已经开始毕业工作了都没能等到无虚拟DOM版Vue的发布。这个时间拖的有点太长了，甚至从Vue2到Vue3都没用这么久。
可以看到Vue3从立项到发布也就不到两年的时间，而Vapor呢？从立项到现在已经将近5年的光阴了，已经比Vue3所花费的时间多出一倍还多了。所以现在的首要目标是先实现出来一版能用的，后面再慢慢进行优化。我们工作不也是这样么？先优先把功能做出来，优化的事以后再说。那么具体该怎么优化呢：
现在的很多渲染逻辑继承自原版Vue3，但无虚拟DOM版Vue可以采用更优的渲染逻辑。而且现在的Vapor是跟着原版Vue的测试集来做的，这也是为了实现和原版Vue一样的行为。但这可能并不是最优解，之后会慢慢去掉一些不必要的功能，尤其是对性能产生较大影响的功能。