这波React真的被针对了

大家好，我是Kason。昨天开心上网的时候，看到一个框架测评，效果真的很爆炸。作者用React和Solid.js开发了同样的Demo。为什么要用Solid.js和React来比较？我们再看看Solid.js的API：HooksContext,PortalAPIErrorBoundaries不能说和React很像，但是一模一样。而且，Solid.js还使用JSX来描述视图，因此将React应用程序更改为Solid.js应用程序的成本非常小。具体评测结果如何？差异几乎快了三倍。这波React真是有针对性。本文指的是SolidJSvsReact：我在两个库上构建了相同的应用程序。[1]为什么会有这么大的差异？简单介绍下这个demo，初始渲染一个空白列表：第一次挂载完成后发起请求，渲染列表数据：RickandMorty这无疑是ChromeDevToolsPerformance面板的两个应用的结果：左边的React和右侧的Solid.js。解释一些关键指标：Loading：发起网络请求和解析HTML的时间Scripting：解析、编译、执行JS的时间（包括垃圾回收时间）Rendering：样式和布局计算Painting：paint、composite、decodedpicturesFocusonScripting具体来说，左边475ms（React），右边176ms（Solid.js）差距不止一倍，这么夸张？问题出在哪个前端框架的工作流程可以概括为三个简单的步骤：触发交互计算交互会影响哪些DOM执行DOM操作这里的交互可能是首屏渲染，也可能是一个点击引起的状态变化，可能是对数据的请求.....在React中，第2步是在运行时完成的，而在Solid.js中是在编译时完成的。具体来说，这一步在React中被称为reconcile，更通俗的说法是虚拟DOMdiff算法。在Performance面板下的CallTree中可以看到在执行XHRLoad（请求列表数据）之前有一个耗时的操作（FunctionCall），就是reconcile。在Solid.js应用中，没有这种耗时的操作：在编译时，Solid.js会直接将JSX编译成状态与操作DOM的方法之间的连接。由于JSX过于灵活，为了在编译时有更多的线索建立这种连接，Solid.js在React原有的JSX组件的基础上提供了一些控制流组件：例如下面是在两个框架中遍历列表项实现区别在：//React

{list.map(item=>
• {item.name}
)}

//Solid.js
{(item)=>
• {item.name}
}
For组件替代了JS中的数组映射方法。当Solid.js在编译时完成这些任务时，它实际上只需要在运行时为每个更新完成步骤1和3，从而节省大部分时间用于步骤2。虽然React有协调的优化策略，但随着应用程序大小的增加，或者项目成员没有完全遵循最佳实践，这将不可避免地导致在步骤2上花费的时间越来越多。Solid.js预先建立状态和操作DOM的方法之间的关系。虽然在运行时保存这个对应关系需要占用更多的内存，但是在步骤2中节省了大部分时间，是典型的空间交换。时间策略。总结了这么多，虽然看起来Solid.js在框架的某些方面比React有优势，但也无法撼动React的霸主地位。毕竟，React的流行与快不快没有关系。最重要的是社区的生态繁荣。还有一个有意思的地方，这里是文章中的两个Demo地址：Solid.js版本[2]React版本[3]Demo中获取数据的API域名为rickandmortyapi.com，有这样一个网站......参考资料[1]SolidJSvsReact：我在两个库上构建了相同的应用程序。：https://dev.to/ogzhanolguncu/solidjs-vs-react-i-ve-built-the-same-app-on-both-libraries-4cfa[2]Solid.js版本：https://github.com/ogzhanolguncu/rick-and-morty-solidjs[3]React版本：https://github.com/ogzhanolguncu/反应瑞克