最近风靡一时的 ” No DomDiff “ 潮流是怎么回事？Virtual Dom不香了？

457次阅读  |  发布于3年以前

前言

前端框架经过这几年井喷式的发展，虽然各家依然是有自己的一套独特风格或特性，比如: 随着v18的逐渐稳定，react在追求异步渲染，快速响应这条路上越走越远；vue3则通过将reactive等更基础底层的Api直接暴露给开发者，这使得它在基于Proxy引擎构建的Mutable响应式编程上践行的更加彻底... 但总体而言，框架的核心技术与特性都已十分趋同。现在如果让自己设计一个全新的前端框架， 也许会面临以下抉择：

1 . 核心原理的选择:

2 . 更新粒度的选择:

3 . 是否采用虚拟Dom： 这个选择是与上边采用何种粒度的更新设计紧密相关的：

4 . 开发语法DSL选择：

5 . 其他支持特性：这点就比较琐碎了，比如Suspence、Portals、Fragments、Context、Streaming SSR等。

机智的你一定察觉到，这么多的技术选择之间其实存在着某种紧密的联系。这也不难理解，因为这些技术选项最终都是为框架的设计目标服务，正如vue追求的渐进式、React追求的快速响应。

差异化竞争在任何领域都存在，前端框架的世界也不例外。总会有后发制人的小众流派去试图挑战一些权威实践，用一些非常规的手段去直击开发者的痛点，做出自己的差异化。最近在国外很火的SolidJS、Svelte就是这样,一个类React、一个类vue，都是节点级、非虚拟Dom的框架代表，他们都宣称在 性能 或者 独立分发组件方面做出了自己的特色，接下来就带你一探究竟。

正文

虚拟Dom是让应用变得更快还是更慢了？

JS Framework Benchmark是一个评测JS框架性能的测试工具，类似于测试手机性能的跑分软件，SolidJS的作者用这款工具测试了市面上几乎所有JS框架，并跑出了第一的好成绩，详细测试流程见它的官网。它究竟是怎么做到的呢？

它的github首页第一条特点就深深吸引了我的注意：

image.png

一直以来，虚拟Dom作为前端领域比较火的一个技术，被认为是提升js框架性能的利器。但是这其实是一直以来的误解，在状态与Dom操作之间抽象出一层虚拟Dom，需要牺牲一定的运行时性能，并不一定比直接操作原生Dom快，要看情况，毕竟diff并不是免费的。

就拿引入虚拟dom较早的React来说，它可从来没有说过 “React 比原生操作 DOM 快”。因为它的基本思维模式是每次有状态变动就重新渲染整个应用。如果没有 Virtual DOM，简单来想就是直接重置 innerHTML。很多人都没有意识到，在一个大型列表所有数据都变了的情况下，重置 innerHTML 其实是一个还算合理的操作... 真正的问题是在 “全部重新渲染” 的思维模式下，即使只有一行数据变了，它也需要重置整个 innerHTML，这时候显然就有大量的浪费。这才是为什么要有 Virtual DOM的原因：它保证了

SolidJS简介

类React框架很多，但SolidJS最像....

image.png

这简直是React hooks的双胞胎兄弟... 而且因为SolidJS这种后发优势，没有React沉重的历史包袱，比如不需要处理类组件的兼容（SolidJS只支持函数式）这让它在实现了大部分React功能特性的前提下，源码体积要比React小很多，这让它在首屏加载方面就首先占据上风。直接调用编译好的DOM操作方法，省去了虚拟DOM比较这一步所消耗的时间，整个更新链路相比React变得简洁许多。 这是React的调用栈

这是SolidJS的

笔者在试用这个框架一天之后，发现还是挺有意思的，总结起来有一下几点。

image.png

在createEffect副作用回调执行，依赖了A、B状态，但并没有像React中那样需要手动维护一个dep数组。

所以：SolidJS = React + vue3？这个答案见仁见智，但是它的响应式实现确实是与vue一样，都是基于发布订阅的依赖收集去做的，但它没有采用vue虚拟Dom的运行时diff，而是充分在编译阶段做文章，将状态更新编译为独立的DOM操作方法。这给它带来了另一个优势：有利于独立分发组件。

独立分发组件

这里我换另一个与Solid原理很类似的Svelte框架做示例，它比SolidJS的编译时做的更加彻底。比如这段模板：

<a>{{ msg }}</a>

会被编译成如下代码：

function renderMainFragment ( root, component, target ) {
 var a = document.createElement( 'a' );

 var text = document.createTextNode( root.msg );
 a.appendChild( text );

 target.appendChild( a )

 return {
  update: function ( changed, root ) {
   text.data = root.msg;
  },

  teardown: function ( detach ) {
   if ( detach ) a.parentNode.removeChild( a );
  }
 };
}

可以看到，跟基于 Virtual DOM 的框架相比，这样的输出不需要 Virtual DOM 的 diff/patch 操作，自然可以省去大量的运行时代码，所以，它对运行时的依赖非常小，但是这有什么重要的呢？

大家在项目开发中，是否遇到过如下痛点:

A项目的某个组件与B项目的非常类似，但当你想复用时，发现一个是用React写的，一个是vue写的，技术栈并不统一，那么这种情况下除了重写之外，你想试图通过将现有组件单独打包，在A项目里直接引用编译后的代码。因为下意识会认为编译后的代码总该是能复用了。但是却忽略了重要一点，无论是vue，还是react在编译后的代码里也是包含有比较重的运行时的，主要就是虚拟dom的diff还有一些别的内部api。那说了这么多，上边的问题有什么实质的解决方案吗？答案是： WebComponent，这是w3c推动的，与技术栈无关的一个组件标准。虽然现在看，它还不够成熟，面临许多的问题要解决。但假如有一天，它的标准化及兼容问题都解决了，这对Svelte这类的重编译时，几乎不依赖运行时的框架是一个非常大的利好。大家可以畅想一下，通过这类框架直接编译一个WebComponent，处处都可以粘贴运行，这是一件多么棒的事情。

尾巴

本文讲了非采用虚拟Dom的框架的一些优势，但它们也面临因此带来了的不足，比如他们先天的因为缺少虚拟dom这层抽象，导致不利于跨平台渲染；在真实的企业级项目中（非BenchMark的demo级别）性能是否比采用虚拟Dom更加优秀，也是一个疑问，毕竟目前很少有大型项目抛弃主流而采用这么小众的框架去试水。所以，目前主流的前端框架，在各自优势上深耕这么多年，不是那么容易说颠覆就颠覆的，本文更多的是开拓一下读者的思路，兼听则明，换句话说，如果读者非要犟一些细节，那么一定是你对。。。（喷子后遗症）

Copyright© 2013-2020

All Rights Reserved 京ICP备2023019179号-8