这波React属实被针对了

大家好,我卡颂。

昨天在网上愉快冲浪时,看到一篇框架测评,效果属实爆炸。

作者用ReactSolid.js开发了同样的Demo。为什么用Solid.jsReact对比呢,让我们看看Solid.jsAPI

  • Hooks
  • Context、Portal API
  • Error Boundaries

不能说和React多雷同,只能说一摸一样吧。而且Solid.js也用JSX描述视图,所以一个React应用要改为Solid.js应用的成本很小。

具体测评结果怎么样呢,差了快3倍,这一波React属实被针对了。

这波React属实被针对了_第1张图片

本文参考 SolidJS vs React: I've Built the Same App On Both Libraries.

为啥差这么多

简单介绍下这个Demo,初始渲染空白列表:

这波React属实被针对了_第2张图片

首次mount完成后发起请求,渲染列表数据:

这波React属实被针对了_第3张图片

这是两个应用Chrome Dev Tools Performance面板的结果:

这波React属实被针对了_第4张图片

解释下其中几个关键指标:

  • Loading:发起网络请求、解析HTML的时间
  • Scripting:解析、编译、执行JS的时间(包括垃圾回收时间)
  • Rendering: stylelayout计算
  • Painting:paintcomposite、解码图片

具体关注Scripting,左475ms(React),右176ms(Solid.js

2倍多的差距,这么夸张?

这波React属实被针对了_第5张图片

问题出在哪

前端框架的工作流程可以简单用三个步骤总结:

  1. 触发交互
  2. 计算交互会影响哪些DOM
  3. 执行DOM操作

这里的交互可能是首屏渲染,可能是点击造成的状态变化、可能是请求数据......

React中,步骤2是在运行时完成的,而在Solid.js中是在编译时完成的。

这波React属实被针对了_第6张图片

具体来说,该步骤在React中被称为reconcile,更普遍的称呼是虚拟DOMdiff算法。

Performance面板下面的Call Tree中可以看到,执行XHR Load(请求列表数据)前有个很耗时的操作(Function Call),该操作即reconcile

而在Solid.js应用中就没有这个耗时的操作:

在编译时,Solid.js会将JSX直接编译为状态操作DOM的方法之间的联系。

由于JSX太过灵活,为了在编译时有更多线索建立这种联系,Solid.jsReact原有JSX组件基础上提供了一些控制流组件

这波React属实被针对了_第7张图片

举个例子,下面是遍历列表项在两个框架中的实现区别:

// React
    {list.map( item =>
  • {item.name}
  • )}
    // Solid.js
      {(item) =>
    • {item.name}
    • }

For组件替代了JS中的数组map方法。

Solid.js在编译时完成这些工作,在运行时每次更新实际只用完成步骤1和3,省去了大部分步骤2的时间。

虽然Reactreconcile有优化策略,但随着应用体积增大,或者项目成员不完全遵守最佳实践,势必会造成在步骤2上花费的时间越来越多。

Solid.js提前建立状态操作DOM的方法之间的联系,虽然需要在运行时占用更多内存保存这种对应关系,但是却省去了大部分步骤2的时间,是一种典型的空间换时间的策略。

这波React属实被针对了_第8张图片

总结

说了这么多,虽然看起来Solid.js对比React在框架的某些方面是有优势的,但并不能撼动React的统治地位。

毕竟,React这么流行和他快不快一点关系都没有,社区生态繁荣才是最重要的。

还有个有意思的事,这里是文中的2个Demo地址:

Demo中获取数据的API的域名是rickandmortyapi.com,居然还有这种网站......

欢迎加入人类高质量前端框架研究群,带飞

你可能感兴趣的:(这波React属实被针对了)