React 劝退贴！
大家好，我是 ConardLi。
在前端圈，一个亘古不变的话题就是前端框架之争，开发者们热衷于吹捧自己喜欢的框架，同时批评其他的框架。其中站在风口浪尖的框架就是 React 了，它作为当前前端框架的 “老大” ，多年来一直在承受着各种批评和争议，同时也在这些批评中不断成长。
今天的文章很有意思，文章中总结了从 2014 年以来 React 成熟的多个重大的争议和批评，所以这篇 “React 劝退贴” 名副其实了～ 其中有一些点已经得到了解决，还有些似乎还在摇摆不定，想要入坑或者已经入坑 React 的小伙伴推荐好好读一读～
本文的多个观点取自 Zach 的个人总结：https://www.zachleat.com/web/react-criticism/
注：本文只是汇总网络上对
React批评的观点，我个人对React还是比较喜爱的 ～
[2014-12-12] 研究 JavaScript MVC 框架的性能成本
【研究 JavaScript MVC 框架的性能成本】https://www.filamentgroup.com/lab/mv-initial-load-times
本文观点主要集中在对客户端渲染性能的质疑。据我所知，这是对 SPA/客户端渲染模型 的第一个有数据支撑的批评。测试结果显示 React 在 3G 移动设备上首次渲染的平均性能基准为 1.26 秒，而推荐的性能指南建议的目标是在一秒内完成首次渲染。
Facebook 的 CEO 马克·扎克伯格曾在 2012 年的讲话中表示在移动端 HTML5 上下了太多赌注，他的原话是这样说的：
我们今天已经可以使用一些实用的方法来可靠地产生非常快的渲染时间，但是我认为
HTML内容从服务器端交付而不是仅在客户端生成，是最有效的方式。除了性能之外，这种方法还有利于用户体验的许多其他领域……
但值得注意的是，在这篇文章撰写 8.2 年之后，React 文档仍然在主要推荐客户端渲染：
“如果您正在学习
React，我们建议您使用Create React App。这是尝试React和构建新的单页客户端应用程序的最流行方式”
有趣的是，他们在最新的 Beta 文档中指定 Next.js 作为官方选择的全栈框架。
[2015-04-10] DOM 并不慢，抽象让它变慢
【DOM 并不慢，抽象让它变慢】https://webreflection.blogspot.com/2015/04/the-dom-is-not-slow-your-abstraction-is.html?m=1
DOM 本身的速度是非常快的，但是过度的抽象让它变慢，主要是反驳《操作 DOM 很慢》这样的观点。在 React 和 underscore、paperclip 以及原生 DOM 操作的性能测试结果中显示，React 的性能最差。
当然看待一个框架不能只停留在性能上，本文的观点比较片面，框架的抽象还给我们带来了编码设计、复用、封装等上面的优势。
[2015-07-03] React + Performance = ？
React + Performance = ？https://aerotwist.com/blog/react-plus-performance-equals-what/
作者分别用一台 PC 设备（MacBook Pro）和一台移动设备（ Nexus 5）中对 React 和原生 DOM 操作进行了性能测试。
下边的结果体现了让 React 一次添加 100 张图片（每张图片大约有 5 个 DOM 元素，包括名称、链接等），从 100 张开始添加到 1200 张的时间变化。
React 在 PC 设备上（性能表现波动不大）：
原生 DOM 操作在 PC 设备上（耗时比较稳定，而且耗时比 React 操作要快很多）
React 在移动设备上（随着 DOM 元素的增多，渲染时间逐渐上涨）：
原生 DOM 操作在 移动 设备上（且耗时比 React 操作要快很多，而且随着节点的增多，渲染时间居然有所下降，这可能是源自 V8 的某种优化措施）
在本文的测试结果中表现了 React 的性能成本非常高，在移动端设备上尤为突出。
[2016-06-13] React 首页变化
https://fosstodon.org/@thomasapowell/109819540720439366
React 的主页发生了变化，删除了宣传 Virtual DOM 性能优势的文案，转而关注效率。
在此更改之前，它声明：
“
React抽象出了虚拟DOM，提供更简单的编程模型和更好的性能。
[2016-07-16] 百度要求内部全面停止使用 React / React Native
https://www.zhihu.com/question/65437198
在 2016 年 7 月，React.js 开源许可协议中的附加专利条款引起了激烈争论。
大概意思如下：
如果您正在或考虑在项目中使用
React，您可能需要咨询律师。由于专利条款，您不得做任何构成与React的许可将立即被撤销。如果您与使用React的任何其他公司发生法律纠纷，如果您有任何法律纠纷，您的许可证也会被撤销。
和 Facebook 有竞争关系的公司都有可能被取消 React 许可？所以引发了国内很多科技公司对 React 的 “弃用潮”。
[2016-12-10] 当一切都很重要时，什么都不重要
【当一切都很重要时，什么都不重要】 https://aerotwist.com/blog/when-everything-is-important-nothing-is/
这篇文章很早就批评了使用虚拟 DOM 的服务端渲染框架如何仍然以非常糟糕的方式阻塞主线程：
SSR通常会让你更快地完成First Meaningful Paint。这对于感知性能来说非常好，但是对于使用虚拟DOM的库/框架来说，TTI似乎又被推迟了。我想通过Diff真正的DOM来制作VDOM是不是比完全重新创建 DOM 的成本要更大？
这篇文章的渐进式引导部分很像是现在被推崇的 Islands 架构的前身，它们都更多地推荐使用 requestIdleCallback 来优化渲染，当然后来的 React18 也借鉴了类似的优化方式。
[2017-07-15] React 被归类为 Category-X 许可证
2017 年 7 月 15 日 React 的开源许可证（带有专利条款）被 Apache 软件基金会归类为 Category-X（有问题的）许可证，这意味着它不能用于 Apache.org 相关的项目。
在随后的一个月后，WordPress 的创始人写了一篇文章，指出 WordPress 的一些正在开发中的大型项目 Calpyso 和 Gutenberg 将停止使用 React。
在随后的几天后，Facebook 决定在 React16 版本中推翻自己的专利条款...
但是， Facebook 的许多其他开源项目（以及 React 的所有先前版本），专利条款仍然有效。
[2017-08-24] React 的兼容性问题
https://github.com/facebook/react/issues/11347
Rob Dodson 提交了一个 RFC ：Plan for custom element attributes/properties in React 17、18、19，在其中指出了很多 Web 组件和 React 之间的兼容性问题。
时至今日，在 React18 的 beta 版本中，React 仍然有很多兼容性问题：
[2029-04-21] Javascript 框架的成本
对 430 万个 PC 和 540 万个移动端 URL 的研究测试表明，与使用 Angular、Vue.js 或 jQuery 构建的网站相比，React 网站在主线程上花费的脚本相关 CPU 时间要多得多。
[2021-10-14] JavaScript 框架 TodoMVC 打包大小
【JavaScript 框架 TodoMVC 打包大小】https://dev.to/this-is-learning/javascript-framework-todomvc-size-comparison-504f
在这篇文章中分析了使用不同的 JavaScript 框架实现一个 TodoMVC 项目，最后打包出的包大小比较 （下面的结果中展示的是经过 Brotli 压缩后的包体积）。
对比结果很尴尬，Preact、Svelte、Solid 这些框架的运行时都非常小，而 React 的 vendor 包体积要比它们都大出 10 倍以上，当然这个结果统计不太客观，上面只是统计一个在实现一个简单项目的打包情况，下面还有实现不同 TodoMVC 组件数量对应包体积的大小变化：
可见，在小型项目中 React 包体积的问题比较明显，当项目逐渐变大，React 才逐渐体现一些优势。
[2022-09-20] React 我爱你，但你太让我失望了
这篇文章很有意思，以一个第一人称的角度表达了对 React API 设计和一些其他用法设计的吐槽，包括以下这些方面：
表单处理困难：开发者必须在
受控输入和非受控输入之间做出选择，受控组件的推荐写法非常冗长；访问
DOM困难：框架不推荐开发者直接访问DOM，然后推荐使用ref，代码库经常可以见到上下传递ref的情况，react.forwardRef设计的也很难用；上下文敏感：由于在设计上可能会出现重复渲染的问题，强迫开发者自己使用
useMemo或useCallback，这大大增加了框架的理解和使用成本；API 理解困难：
useEffect设计的非常复杂，存在很多使用不当的情况，为了理解它，有开发者写出了53页的论文；核心 API 不断膨胀：为了解决
useEffect等API带来的问题，又推出了useEvent、useInsertionEffect、useDeferredValue、useyncwithexternalstore等等新的用法，对开发者来讲好像在给猪身上涂口红；
[2023-02-06] Core Web Vitals 网站分析报告
【Core Web Vitals 网站分析报告】https://lookerstudio.google.com/reporting/55bc8fad-44c2-4280-aa0b-5f3f0cd3d2be?s=lD9m_MQgyGU
在一项对大约 930 万个网站的 Core Web Vitals 性能指标的统计分析报告中表明，使用了 React 和 Next.js 网站的 Core Web Vitals 的表现要比所有网站的指标平均统计结果要更差。
Core Web Vitals是
目前只有 25.7% 使用 Next.js 的网站以及 30.7% 使用 React 的网具有比较良好的 Core Web Vitals，低于数据集中所有站点的统计数据(38.5%)
最后
「怎么样，阅读完这些劝退观点之后，你对 React 的热爱是否动摇了呢？欢迎在评论区留下你的观点。」
参考链接
https://www.zachleat.com/web/react-criticism/ https://github.com/krausest/js-framework-benchmark https://www.youtube.com/watch?v=uCHZJy2n8Qs https://www.swyx.io/svelte-static https://emmas.site/blog/2020/09/12/react-is-a-subsidy
如果这篇文章帮助到了你，欢迎点赞和关注。
如果你想加入高质量前端交流群，或者你有任何其他事情想和我交流也可以添加我的个人微信 ConardLi 。
点赞和在看是最大的支持⬇️❤️⬇️