Robust第028期:2021年前端UI框架发展趋势

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的能力。其中的典型代表是alpinejshttps://alpinejs.dev/)。 你加载它的库之后,你可以使用15种新attribute6个新property2个方法。直接在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 60

为价值买单

本文价值0.6RMB