7

关于前端框架的另类思考

 4 years ago
source link: https://zhuanlan.zhihu.com/p/261080218
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

关于前端框架的另类思考

前端玩票,高产玩具,fre,fard,berial,ep……

halo 大家好,我是 132,我决定还是写一篇文章再来谈论前端框架,这次我们换一个角度,我们不谈函数式,不谈各种机制的优劣,我们从最原始的角度去讨论框架的各个机制

这里面有一些「另类」的观点,改变一个人尤其是框架作者的认知是非常困难的,这种改变只能靠自己,我写这篇文章只是为了阐述我的观点,而不是让任何人拥有同样的观点

web 平台的性能瓶颈不在于 dom 操作

大家在纷纷引入 vdom 的同时,基本认知是「性能瓶颈在于 dom 操作,diff 算法是用来减少 dom 操作的」

这种认知当然是非常错误的,因为实际上我们的电脑越来越高配,浏览器性能越来越好,就现代浏览器来说,你操作十万个 dom 也就几秒钟的事情,根本谈不上「性能瓶颈」

所以拼命优化 diff 算法是一种钻牛角尖的行为,因为你的优化都是毫秒级别,意义小的可怜

web 平台的性能瓶颈在于线程阻塞

线程阻塞,也就是 js 线程阻塞 UI 线程,io 线程阻塞 js 线程

这种瓶颈是真的会卡到你怀疑人生的,一旦造成了线程阻塞,就会卡的不要不要的

所以单纯对 web 平台来说,diff 算法的意义很小,还不如没有呢,dom 操作的成本真的很低

但是线程阻塞的问题不是你通过算法就能解决的

所以才有了 fre/react 的时间切片和可恢复异常,它们解决的是瓶颈问题

vdom diff 的真正作用

很好,大家都知道了,web 平台做 diff 意义不大

很多框架作者此时就会出来说「权衡」,我们要的不是 diff 的性能,而是 vdom 的抽象层次,diff 只是权衡后的结果

这么说也没什么错,vdom 确实是一种很好的抽象机制,diff 提升性能也是不做白不做

但却不是必要的,所以 web 平台才有了一堆 without vdom 的框架,比如 litelement,svelte,他们放弃 vdom 的时候,都阐述了「为什么不需要 vdom」

但 vdom 其实是有用的,我们要说另一个平台

RN 平台的性能瓶颈在于线程通信

其实这才是 vdom diff 产生的刚需,我们线程通信,说白了就是将操作指令,发送到另一个线程

但是线程通信的成本很高,所以我们需要考虑,1. 减少通信次数 2. 减少通信体积

vdom diff 就是干这个,他们经过 diff 最终产生「最小的 dom 操作指令」,然后发送给另一个线程

之所以可以这么做是因为,RN 的 js runtime 不值钱,就是你可以浪费 js 引擎的性能,去交换线程通信的成本

所以大家经常说 vdom 跨端,实际上是用来干这个的,当然 ssr 是另外一回事

小程序平台的 runtime 也尤为珍贵

小程序很特殊,它不仅有线程通信,还有 webview,导致它其实两方面的性能都是瓶颈,不仅仅是线程通信是平静,实际上 js runtime 也很值钱

比如,胖总:Vue 性能优化 - 去除 VNode 这篇文章就干过类似的事情

所以很明显,小程序底层框架

  1. vdom 不合适,因为小程序的 js 的 runtime 也是瓶颈所在,浪费不起
  2. 线程通信的平静依旧存在,我们仍然需要得到最小指令

那怎么办呢?没办法咯,我们只能用电脑的性能去换 runtime 和线程通信的性能了

通过编译手段得到最小的 dom 指令

这里就不得不提到一些编译型框架了,比如 svelte,svelte 的本质其实就是通过变异,编译出来一些带有条件判断的代码,进而更小的操作 dom

它牺牲的是编译期间的性能(也就是用户电脑的性能)和生成的 js 代码量

这个思路是很 ok 的,也可以说是最适合小程序的平台的思路

当然大家肯定会说,为什么 taro/nanachi 这种,也是编译思路,还不是被淘汰了,其实不能这么说,他们的编译只是个表面功夫,完全触碰不到瓶颈本身

所谓权衡

权衡这俩字,快被框架作者们用吐了,但其实权衡分两种

  1. 先做,再编理由瞎扯
  2. 先搞懂是什么,再研究怎么做

举个例子,fre 是先搞了时间切片,然后我写了这篇文章,说时间切片才是 web 平台的瓶颈所在,属于前者

但如果让我现在去写一个小程序框架,我不会用 fre,因为经过很多思考,我认为 vdom 不合适,fre 也不合适,这就属于后者

判断力永远都是一个人的事,我觉得真的不能当傻子,任何框架作者说的话,都是好坏参半,等你自己写框架了,就能参破了

总结

这篇不是 fre 的广告帖,如果我加入一家公司,负责小程序架构,我会再写一个更合适的框架,而不是无脑地组合各种机制,无脑的用一个框架,跨各种端

现在的前端世界很糟糕,大家都在瞎搞,缺少了很多思考

其实一个框架有没有人用,火不火根本没所谓,至少对我来说没什么所谓

我写框架只是我的判断力驱使我这么做,我无法改变别人的认知,只好自己写一个出来

以上,不喜勿喷呀


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK