2021年的前端框架又有了新的发展，本期将总结以往的前端框架，梳理前端框架脉络，一个一个的梳理前端框架与其他框架的不同之处。最后，实现一个我们自己的框架。

在线收听

喜马拉雅：点击播放

网易云音乐：点击播放

你还可以在苹果自带的 Podcast 应用、小宇宙APP、QQ音乐中搜“Robust”找到我们的节目收听。

捐赠支持

求打赏🙇如果你觉得 Robust 这样一档技术类的谈话节目还不错，希望我继续做下去，不妨打赏支持。

内容文案

本期将总结以往的前端框架，梳理前端框架脉络，一个一个的梳理前端框架与其他框架的不同之处。最后，实现一个我们自己的框架。

首先，我们来看下jquery，它是一个基于DOM操作的封装库，它包含了DOM、BOM的操作，以及在这些操作中需要的一些方法。它的与众不同在于接口的简单和对DOM的管理的简洁性。通过jquery来操作DOM，完成UI更新，这是早期的js框架backbone的基础。backbone有View和Model，Model管理数据，View更新UI，两者绑定之后，Model上的数据更新时，会触发View里面的更新操作，通过jquery操作DOM的方式完成UI更新。

但是，在backbone中，我们需要根据数据，主动的拼接html字符串来插入新的DOM。这种原始方式在遇到handbars这个模板引擎的时候发生了变化，handbars是我接触最早的类似大家熟悉的vue模板使用插值的模板工具，基于handbars，你只需要传入其中需要的数据，就可以快速生成html字符串，这样就可以避免backbone中手动拼接出html字符串的繁杂。emberjs正是基于handbars的大型重量级框架。我在使用emberjs时，就已经用上了es6的语法。

模板+数据生成DOM，仍然需要开发者手动处理这些生成的DOM，有没有一种方式，我们根本不需要关系基于模板的UI，我们只需要关心数据就可以了？angularjs横空出世，它基于脏检查的机制，可以在你修改$scope上的属性后，基于$digest自动去计算当前的界面是否需要更新。

脏检查机制是第一个全自动的界面更新机制。它的机制大概是这样

• 在controller第一次实例化的时候，注册watcher
• 建立$scope和视图的绑定
• 渲染视图
• 当用户点击按钮或内部自动发起网络请求时，实际上是调用了ng-click绑定的回调函数或$http服务，而angular对这些自己系统内建的机制进行处理，你可以简单理解为，在这些函数执行后，被跟着调用了一个叫$digest的函数
• $digest函数实际上就是触发angular的脏检查开始
• 脏检查机制会去检查模板中会使用到的$scope上定义的属性是否和之前的属性一致
• 前面我们提到用户点击，点击的回调中，我们经常会修改$scope属性，因此，在检查它的值是否一致时，如果不一致，就记录下来，之后用来更新视图
• 另外，前面我们提到注册了一些watcher，这些watcher指定了要检查哪些属性，也就是在脏检查开始后，这些watcher函数就会被执行，至于执行时是否要修改另外的属性，由开发者自己决定
• 你会发现，一次检查过程中，有可能watcher内还会再修改被依赖的属性，这导致你必须再做一轮检查，看看是不是有属性被修改了
• 那怎么决定是不是还要检查呢？angular在每次检查的时候，就会用一个dirty变量记录，只要这次检查发现有属性和上一次的值不一样，就dirty=true，这样，就必须在检查一次
• 如此循环，直到dirty为false为止
• 但是，如果你在watcher中动态修改属性值，有可能造成循环永远都没有办法跳出，导致死循环，所以angular规定了一个循环的上限，达到这个上限之后，即使dirty为true也跳出

通过脏检查机制，angularjs在自己的体系内真正做到开发者根本不需要关心更新视图，怎么去更新视图的问题，而且最好不要自己去更新DOM。当然，开发者还是有机会用DOM的那一套修改视图。

脏检查机制费时费力，它不仅要做循环检查，而且还要检查那些根本没有变化的值。有没有一种可能，只检查发生变化的值，或者更进一步，我这个值变化的时候，才去检查。这就是vue2做的事情，它通过defineProperty直接监听Vue实例的属性变化，也就是说，只有属性变化的时候，才会触发内部的更新机制。这就可以大大节省视图真正更新之前所做的是否要更新的判断过程。

Vue2借鉴参考了angular的设计，同时也有自己的创新。但是，vue的模板仍然是一种传统的表达形式，开发者必须在脑海中严格区分UI的部分和js代码控制的部分，视图层本身还是割裂的，就是你需要通过两个甚至三个地方去跳跃式的组建出一个视图出来。vue带来了sfc很好的提供了一种把这三个东西汇聚在一起的方式，这是一种极好的设计。

但是，facebook的工程师不这么想，它们认为，视图和js代码实现的逻辑，应该是一个整体，我们在写js的同时，实际上也应该在写视图。于是他们发布了react，里面用到了jsx技术，把基于js实现的逻辑和视图本身统一在一起。对于react而言，视图不再是以前的html模板思维，而是一个对象。这对基于模板的框架而言，是一种降维打击。你可以这样思考，我们三维空间的人对时间这个事物没有把控力，只能任由时间流逝，时间是组成我们生命的一部分，这是我们传统的思维。现在来了一个五维空间的人，在他的世界里，时间是可以把控的事务，他在穿越时间时，就像在爬一座山一样，是有形的。这个时候，三维空间的人和五维空间的人打架，他就可以降维打击。对于facebook的工程师而言，视图就是刚才例子里面的时间，在以前的观念里，视图一定是基于html字符串出来的东西，而到了react里面，视图称为js对象，这个对象放在一个js的代码逻辑中，开发者自己自由组合。这种降维打击对整个前端的冲击不小。

react怎么做到把视图当作一个对象？它使用了一种叫virtual dom的技术，在react中，视图对象是virtual dom，与真实的DOM之间还存在一个转化的过程。因此，对于react而言，视图仅仅是一个描述，至于这个描述怎么映射到真实DOM，开发者不用关心，总而言之，只要你virtual dom的结果确定，就一定会得到与之对应的DOM界面。当然，这种映射就要求开发者自己不能主动去操作DOM，必须由react来更新DOM。

基于这个理念，既然virtual dom可以与真实DOM有1:1的映射关系，那么是否存在另外一种可能，virtual dom这个庞大的对象，与另外一个规模很小的数据也存在1:1的映射关系。angular、vue都给出了答案，是有这样的映射关系的，比如你的virtual dom是一个1M的大对象，但是，里面用到的数据只有a这个变量，那么对于react开发者而言，根本不需要关心virtual dom是多么的复杂，他只要关心我这个a在什么时候要变成什么值，因为a为一个值的时候，它和virtual dom之间有1:1的映射关系，最终和DOM就有1:1的映射关系。中间这些映射全部交给react去处理，最后，react开发就变成了管理这个a的整体过程。

react怎么处理的呢？它在组件内建立了一套状态机制，通过setState来更新状态，只要你调用了setState，就代表你想要改变界面，它就会基于新的state，直接创建对应的virtual dom，再基于diff等一些算法，决定更新那些DOM。而且，react直接忽视angular里面辛辛苦苦搞的检查过程，在react里面，根本不检查，只要你调用setState，就代表你修改了状态，就代表你要更新virtual dom，当然，更新virtual dom之后是否更新真实DOM则不一定。

而这一机制有的时候特别蛋疼，明明状态值没有任何变化，但是由于触发了更新机制，原本根本不需要执行的函数还是会被执行。而且，如果当前组件内用到了其他组件，那么这些被用到的组件在接收到新的props时，也会因为数据映射界面的原理，导致组件渲染函数再次执行，而如果这些组件内部又用到其他组件……如此套娃下去，很有可能你的状态根本没变的情况下，所有的组件渲染函数都重新执行了一遍，浪费太大了。所以，利用shouldUpdate进行优化非常有必要。

有没有一种可能，你不要傻傻的去创建virtual dom，能不能做到直捣黄龙的定点更新？从目前来看，react是没有机会了。但是vue3解决了这个问题，和vue2刚发布时已经完全不同了，vue3来到了一个新的时代。此时，编译技术已经在前端有了非常大的灵活度，vue3拥抱新的时代特征，在编译时做了很多事情。虽然vue也是基于virtual dom的，但是和react不同，它的virtual dom基于对模板的解析来完成。这个过程由vue提供的工程工具，在项目构建时进行。Vue3中，构建工具分析模板中节点的特征，如果发现这个节点根本没有依赖任何数据，那它就是一个静态节点，永远都不会变化，对于这类节点，就没有必要在更新阶段再去处理。

如果是这样，那么基于编译时，我们是不是还能做更多事？当然，例如跨平台开发框架taro，阿里的rax系列，uniapp等工具，都是基于编译的好手，但它们始终还是更高层面的应用框架，在底层UI框架中，svelte闪亮登场。svelte是完全基于编译时的ui框架，你必须使用它的一整套编译工具，同时按照它提供的语法进行编写。而正是有了编译的强大加持，svelte的开发给人哇塞的感觉。你在写svelte的组件时有点像写原生的html，但是又有点不同，因为你可以在它的视图模板中使用像类似vue一样的模板语法来使用你在script标签中声明的js变量，于此同时，你还可以在事件回调函数中直接修改这些js变量，更令人神奇的是，你的这个修改竟然能引起界面的更新。

这种接近原生但又对原生web开发超级增强的开发体验感瞬间触了很多前端开发者的G点。svelte的热度也瞬间爆发。svelte在编译阶段去识别那些变量被依赖了，哪些地方注册了一个回调函数，通过这些识别，把原来像html的组件代码，编译出类似vue或react一样的响应式代码，最终出来的代码，和原始的代码，根本没法一一对上。也正是因为编译，它直接丢弃了virtual dom那一套，不需要在状态变化的时候，重新执行渲染函数，得到一个virtual dom。没了virtual dom，它在编译后，直接修改DOM来更新界面。理论上，比基于virtual dom的框架更新起来更快更准更狠。

无独有偶，solidjs也是和svelte一样，利用编译，重写react，也没有virtual dom，用react的开发方式和理念，得到类似svelte一样的更快的结果。

但是，即便火爆如svelte，我至今也没有看到在自己周边有生产环境的项目是用svelte写的。我觉得svelte已经挺成熟了，为啥没有在我周边被大范围应用呢？我想有这么些原因：

• React/vue太香，换技术栈成本大
• 对编译强依赖，脱离了它的工具（runtime）根本没法用（vue也有自己的standalone包）

从jquery开始，到svelte，你看，没有一个框架是完美的。兜兜转转，没有绝对满意的框架，这已经是常态了。所以，触发了我对web本质的思考。什么是web，什么是前端呢？现在的前端已经不局限于web了，所以，基于编译的框架才可以大行其道。

但是，除了react之外，其他的框架还是以web应用为目标。既然以web为目标，为什么一定是编译呢？有没有不需要编译，又能享受这些框架有的一些优点呢？Vue2是一个非常不错的选择。但是，有没有更精简的方式呢？vue的接口确实优点多。2021年开始流行另外一种框架思路，即html流框架。什么意思呢？就是你加载这个框架的文件之后，可以扩展html的能力。其中的典型代表是alpinejs（https://alpinejs.dev/）。 你加载它的库之后，你可以使用15种新attribute、6个新property、2个方法。直接在html代码里面就可以定义作用域。而且，我直接接触过，设计师懂html的情况下，不需要学习js，能基于alpinejs完成页面输出。

现在业界已经有一些共识，框架（这里指工程化框架，而非视图框架）应该往ssr、智能化等方向发展。例如react提出的server components，以及这两年出现的ssr框架。另一方面，基于编译的，esbuild、swc这些基于非js语言的解析器出现，又带来了一些可能性。但是，在web运行时上，这两年的建树并不多，连react都去搞服务端了，留给web运行时的时间不多了。我们现在有webworker，有webassembly，为什么没有出现更强的运行时呢？于是我自己写了一个运行时的UI框架sfcjs，它有svelte的写作风格和无virtual dom的定点更新，有vue的响应式，加载方式是amd按需加载，基于shadow dom隔离样式，基于css变量实现响应式的css，更重要的是无编译，直接在运行时使用。它优点像alpinejs，但是又不是，alpinejs是直接对当前的页面html进行作用域处理，而sfcjs是组件概念，写一个htm文件作为组件存在。所以，它是一个运行时解析执行的ui库。

在前端发展过程中，涌现出了很多框架这里没有提到的，例如雅虎的YUI、国内的avalon、angular2、cyclejs，甚至应用层面的框架nextjs、nuxtjs、甚至国内的dva、umi。而且，还有一个方面，智能化、低代码在这两年盛行，其背后孕示着另外一个事实，即传统前端架构已经无法满足可随意调整界面的需求，一种通过服务端控制的界面，在早几年，百度开源的amis早就实现了用json来渲染界面，你只需要让后端来输出json来驱动页面即可。如果你常喝设计师打交道可能见过figma，它可能是前端应用在技术架构层面的下一代标杆。

今天的内容就这些。我们总结一下，前端框架分两种，一种是视图框架，专注解决视图驱动问题，一种是工程框架，解决项目开发架构的问题。我们今天主要讨论的是视图框架。我们梳理了过去和现在的框架，也思考未来的可能性。对于开发者而言，我们应该拥抱变化，如果内心确定这东西是趋势，就放开心去拥抱，而不要太担心当下用不到的问题。

2021-09-11 2181