流行趋势。不知道你有没有注意到。2021年以来，非虚拟DOM框架/库/编译器备受关注。最典型的两个项目：SvelteSolid.js我们来看看他们有多勇敢：（来自https://www.tecla.io/blog/top-js-frameworks）可以看到Svelte去年在GitHub上的Star增长是接近Vue，甚至打败老牌经典框架Angular！再来看看这个：满意度甚至超越React和Vue，（吐槽：Angular的满意度趋势...）兴趣度同样霸榜，但这次恰恰相反：SveltebeatsSolid，并且VuePressReact（越来越多的人对Vue感兴趣）。Angular的衰落已经显现，是生命的尽头吗？不用担心！下一个选项（Usage）让Angular告诉你，你大叔永远是你大叔是什么意思：奇怪，感觉身边用Angular的人不多，你怎么这么胖？这是因为调查对象主要集中在欧美地区（尤其是美国）：母语为英语的人群居多：主要是年轻人：这完美解释了为什么Solid和Svelte这么受欢迎，年轻人！折腾！如果你到了五十六十岁（中国应该没有这个年龄段的程序员），你是不愿意折腾那些乱七八糟的东西的。年轻不代表你是新手，参与调查的有不少经验丰富的开发者。数据来源：https://2021.stateofjs.com/en-US/libraries/front-end-frameworks/但是，这些数据仍然不能证明Svelte和Solid已经成为流行的frameworks\libraries\compilers，还有相当多的都叫好不叫座，来看看npm数据：oops！再看看谷歌搜索量：可以看到三大框架依然是主流，Vue和Angular的差距越来越小。部分去谷歌搜索Vue，否则我相信Vue的数据肯定会超过Angular的。数据来自https://trends.google.com/trends/explore?cat=31&date=today%205-y&q=React%20javascript,Vue%20javascript,Angular%20javascript,Solid.js%20javascript,Svelte%20javascript确实没想到对Svelte最感兴趣的还是韩国人！虽然三大框架YYDS，作为后起之秀，没有明显的优势（一般来说，没有人能比得上Svelte只是写HelloWorld），仍然可以在三大框架中分一杯羹。并且还能获得如此巨大的关注度，证明无虚拟DOM的风潮已经悄然兴起。为什么这件事会成为一种趋势？有什么好处？优点是性能！什么？虚拟DOM不就是为了提高性能吗？！是还是不是，我推荐阅读这篇文章：[0]《网上都说操作真实 DOM 慢，但测试结果却比 React 更快，为什么？》他们无缘无故的流行，我们来看看他们的表现：可以用四个字来形容，Vue一直以其高性能而自豪，可是又怎么甘心被超越呢？毕竟，Vue不同于React。当数据更新时，Vue知道更新哪个组件，而React不知道，所以只能使用diff算法，没有虚拟DOM是行不通的。那么为什么Vue需要虚拟DOM呢？游玉玺也是这么想的！其实他早就想过放弃虚拟DOM了：游达在游鱼溪发表的文章《Vue3的设计过程》（翻译版）中说：一种选择是放弃虚拟DOM，直接生成命令式DOM操作,但这将消除直接编写虚拟DOM渲染函数的能力，我们发现这对高级用户和库作者非常有价值。那时，Vue3还没有发布。Vue3的createRenderer使用了虚拟DOM来实现跨平台，但始终是跨平台跨平台的。我们平时开发业务有多少个跨平台项目？我们现在追求的是轻量化。没有虚拟DOM，就没有Diff算法。不仅可以不用进行一些无谓的计算，而且打包后的体积真的是轻巧轻巧！不香吗？但是你不能完全放弃虚拟DOM。一方面，虚拟DOM仍然有其巨大的潜力。另一方面，如果直接删除虚拟DOM，那那些库呢？其中有多少依赖于虚拟DOM的API？有多少组件库使用了jsx：[1]如果去掉虚拟DOM，那些组件库是不是就没用了？然后我们可以想出一个模式！NovirtualDOMmode首先翻译一下有大在发布会上说的（重点部分），为了节省篇幅，不重要的部分就不贴了：主要是：我们想探索一个新的汇编策略我们都知道Vue是一个基于模板的框架。即使可以使用jsx和virtualDOM，大多数用户还是会使用template模板。（一个一个截图太麻烦，我就不截图了，浪费篇幅，我直接写翻译，有兴趣的可以点击视频链接[2]观看.)由于Vue的大部分用户使用单文件组件来编写代码，所以我们实际上有机会将组件编译成原生的JS和CSS。所以这一步编译就有机会让Vue变成超级编译器！这会很有趣，所以我们想探索一种新的编译策略，同样受到Solid.js的启发。新的编译策略可以将模板模板编译成命令式DOM操作+响应式设置绑定，替代虚拟DOM和渲染函数。那么想象一下，当我们这样写一个组件时：（这里省略一些废话：这是脚本设置语法，看到这里是一个按钮按钮，我们给按钮绑定一个响应值等）我们生成的代码将是这样，生成的代码量很小。目前的想法是，我们遍历虚拟DOM树，然后生成真正的DOM操作。我们会在编译时分析template模板中的HTML结构，并将其字符串化：为了尽量减少打包的内容，去掉了结束标签和各种绑定属性。然后生成一个cloneNode：通过分析，哪些属性是响应式的，放到effect中，然后绑定事件，都是非常容易理解的DOM操作：（这个不比Svelte大陀生成的好好多了？）两种模式这里的两种模式不是指虚拟DOM模式和无虚拟DOM模式这两种模式，而是可以进一步细分为无虚拟DOM模式下的两种模式：组件模式，例如，如果你手上已经有一个长期维护的Vue3项目，如果直接切换到非虚拟DOM模式，肯定会有问题，所以可以使用组件模式来精确控制哪些组件不需要VirtualDOM.比如你的项目使用友达推荐的naive-ui组件库。我们打开一个比较常用的组件Button看看：在tsx结束时，虚拟DOM被认为是死了。但是，tsx仍然可以更改为生成真实DOM的函数。这不是solid.js所做的吗？其实理论上是可以做到的。我们点进去再看一下：这里用到了h函数。该函数专门用于生成虚拟DOM。如果同时把所有的项目都改成非虚拟DOM模式的话，这些库还没来得及跟进，肯定不行。所以你可以控制哪个组件你不用这个组件库，你给这个组件一个单独的编译策略（没有虚拟DOM模式）。既然有组件级的，就必然有应用级的。比如你想开发一个UI高度定制化的H5活动页面。一般来说，这类页面不使用组件库，而是自己编写样式。另一方面，活动页面当然是越小越好，越快越好！那么此时就可以使用全局非虚拟DOM模式了。怎么感觉这是在抢Svelte的饭碗？看到技术论坛已经有人分享了一篇关于使用Svelte开发一些小页面的文章。这一次，如果有性能基准之类的评测，Vue应该不会输给Svelte（视情况而定，组件越少，Svelte越占优，否则Vue占优）机遇与挑战最近，前沿-结局变得越来越复杂。如果你要面试一个稍微高级的职位，你可能会被问到Vue如何在两种模式下编译（即使你不感兴趣）。但是我发现很多人对自己做一个组件库很感兴趣。您可以从文章列表中找到与组件库相关的文章数量。而且，很多教你搭建组件库的文章，点赞数也非常高，还有很多文章推荐自己做的组件库。可惜个人做出来的组件库，大多都是自我欣赏，很少有人使用。一方面，个别开发者随时可能删库跑路，不稳定。谁知道你写的东西有多少错误？另一方面，大家更愿意使用Star的众多组件库来证明其稳定性。所以大家想要分一杯羹主流的组件库还是非常困难的。那么这种非虚拟DOM模式现在是一个千载难逢的机会吗？不过我个人还是觉得希望不大，因为那些主流的组件库肯定会马上跟进，打造非虚拟DOM适配版。不管怎样，我真的很期待这个实验性的功能。因为这种编译策略编译成web组件很可能是一个非常好的选择。总之，期待无虚拟DOM的到来！文章链接：[0]:https://www.zhihu.com/question/31809713/answer/53544875[1]:https://www.zhihu.com/question/436260027/answer/1647182157[2]:https://www.bilibili.com/video/BV12S4y1e7pn?p=1&share_medium=android&share_plat=android&share_session_id=4e2c7597-7fa7-4e0a-a098-5e0aa675b035&share_source=WEIXIN&share_tag=s_i×tamp=1655041421&unique_k=nLvKgzv&vd_source=3490d817b36fc42ec9a252b6cd0d6baf
