React 老矣，我建议大家用用别的框架

作者 | Josh collinsworth

译者 | 核子可乐

策划 | 闫园园

如今，纵观各类招聘网站上的前端职位，大家往往都会看到一个熟悉的字眼：React。虽然企业雇主也经常会列出其他一些类似的前端框架选项，但 React 的地位几乎是雷打不动。

但面对这样的现实，请原谅我始终无法理解。除了流行，React 到底还有什么优势？

首先我想澄清一点，我对 React 没有任何敌意。我知道它挺好，而且如果需要开发庞大复杂的前端项目，我其实也并不抗拒使用 React。

React 的出现，为其他框架当前及未来的功能规划奠定了基础。Vue 3 及其组合 API 明显是受到 React hooks 的启发。Svelte 中的很多约定就来自 React。至于我最喜爱的 Vue 框架 Nuxt，它的大部分设计思路都来自 React 的元框架 Next。总而言之，整个基于组件的前端设计和开发模型，特别是目前的整个生态系统，都离不开 React 的鼎力支持。

但就个人观点，我还是觉得 React 像是那种开创了流派的祖师级老电影、音乐专辑或者电子游戏。它的伟大体现在那个时间点上的开创性，但时至今日自身的绝对价值其实已经很有限了。

好吧，这话可能说得有点狠。毕竟一提到开创性的老电影，大家首先想到的就是《公民凯恩》，React 跟其他框架间的差距肯定不像《公民凯恩》相较于后来的经典佳作那么大。我的观点很简单：

React 已经老了，只是经常用它的朋友们还没有意识到它老到了什么程度、引发了哪些问题。

如果只用 React，那可能会觉得这框架不错啊，而且一直在努力改进。确实，React 在很多方面都是越来越好，但这并不能改变它的发展速度和功能上限已经长期跟不上同类方案的事实。

总之一句话，React 表现得不错，只是不像其他框架那么好。

1 工作中的最佳选项

假设大家身为某家科技初创公司的 CTO，或者是打算开发某网络软件新产品的个人创业者。

我们面前摆着新项目的蓝图，可以随意选择自己喜爱的技术进行构建。没有约束，也不设产品生命周期限制，那么你会选择哪一种前端框架？

（有些朋友可能会抬杠说，不用前端框架也行。但对于任何成规模、比较复杂的项目来说，不用前端框架肯定不是什么好主意。）

要做出选择，先要考虑以下几项条件：

• 性能

• 学习曲线

• 绑定包大小

• 可扩展性

• 社区与支持

• 资金支持

• 开发者体验

• 人才供应

而有没有一种可能，从这么多角度来论证，其实 React 并不是什么好选择。

下面咱们逐一探讨。

性能

大家可以通过多种不同指标来衡量性能。但无论关注哪个具体方面，React 都称不上顶级水准。Vue、Svelte、Solid、Inferno 等工具的性能总体上都要好于 React。根据实际需求，大家甚至可以通过 Alpine 或者 Petite Vue 等让性能更上一层楼（虽然我觉得这两种跟其他框架并不算同一类方案）。

React 的性能不佳应该已经是个共识，所以这里无需继续赘述。所以我认为，如果大家希望让新项目拥有强大的性能表现，那 React 就可以直接被排除在外。

学习曲线

假设你对前端框架一无所知，那 React 也绝对不是最好学、最容易上手的选项。

JSX 的实质，就是笨拙地把 HTML 硬塞进 JavaScript 函数返回。你以为这就够糟了？不，更糟的是你在 React 里不用 JSX。

除了 JSX，React 本身也有不少独特的约束和毛病（比如提供两种完全不同的语法，但二者完全无法互操作）。

在 React 中，其他前端框架能够帮我们轻松打理的小事，往往还是需要手动干预或者借助大量样板文件（甚至二者兼有）。

几乎每种前端框架都把用户设想成普通人，但 React 不同，它最早是专为 Facebook 的工程师们打造的。虽然经过多年发展，它已经成为一种比较通行的市场化产品，但即使到现在，这样的出身仍然给 React 留下了深深的烙印。我们还是可以看到其中留下的早期决策与优化痕迹。

至于其他问题，那可太多了。万恶之源 useEffect，不能在 JSX 中使用某些标准 HTML 属性（因为 JSX 无法区分 React prop 和 HTML 属性），记忆化，只能靠短路运算符模仿出来的虚假条件，以及要求开发者自己防止无限循环等等……其实连这里的循环都是假的，必须靠数组方法才能实现。不说了，说不完。

绑定包大小

这一点跟速度类似，但我觉得还是有必要区分开来。哪怕下载包大一点，但实际使用时性能更好，那也没啥问题。但 React 可不是这样。

React 软件包相当臃肿，这个大家都知道了，我也不多废话。

我想强调的是，有些人觉得 React 大多数情况下会从缓存中加载，所以绑定包大小无所谓。这种认知最早是假的，后来现代浏览器让它成了真，可最近的安全升级开始阻止域之间的缓存共享，所以又成了假的。

另外，Preact 虽然表现不错，但还没办法跟 React 无缝对接。而且 Preact 的包大小跟其他前端框架比也没有太大的优势。

可扩展性

虽然 React 对应的企业应用规模肯定是最大的，但我觉得吧，数量跟质量并不是一回事。

从 Vue 到 Svelte，再到 Angular 和 Ember，每一款主流前端框架都拥有类似的大规模执行能力。他们的网站主页上，也不乏一个个声名显赫的重量级客户徽标。

所以 React 没什么特别的，只是案例最多罢了。

如果大家有很强的从众心理，那我也无话可说。但客户多真的不代表 React 就一定更优秀，它只是出现在了充满机会的时代。

社区与支持

没错，React 背后的社区规模最大，但这还是不足以支撑 React 就最好的结论。

大社区也有负面影响，特别是对 React 这类“无倾向性”框架而言。社区过大可能对应着太多可供选择的套餐，太多相互冲突、彼此对抗的观点，逼着用户在其中站队，然后承受随之而来的一切。

不仅如此，社区太大，甚至不一定能让产品越变越好。

最初，更多的参与者确实能不断带来好的功能特性。但这里存在一个收益递减点（即不断上升的沟通成本，逐渐开始减慢、而非加快项目发展速度）。除此之外，社区的参与人数和社区质量间也没有必然关联。

当然，我理解想要去爆满的餐厅吃饭那种心情，这似乎能给人一种安全感。毕竟哪怕不好吃，还有那么多人跟我一起上当呢，这波不亏。但哪怕人再多，都无法改变“不好吃”这个基本事实。这跟愿意来吃的人是多是少，真的没什么关系。所以我们用不着非往最火爆的餐厅去挤，挑一家适合自己的、安静享受一顿美食，不就足够了？

资金支持

有些人总担心自己使用的框架，会在某一天突然消失，由此失去支持和维护。对他们来说，出自 Facebook 系的 React 天然值得信任。但问题是，其他前端项目的资金支持有那么不堪吗？

Angular 的背后可是谷歌，Vue 则是历史上最成功、资金也最充裕的开源项目之一。Vercel 目前至少雇用了两位 Svelte 维护者（其中包括 Svelte 的缔造者）全职负责项目管理。至于 Solid，已经拥有超过 100 名贡献者和至少六家主要企业赞助商。

所以，资金支持对各大主流前端框架来说都不是问题，React 在这方面同样不算占优。

开发者体验

React 确实是应用范围最广的前端框架，知名度也是一时无两。但在今年的 JS 现状调查报告中，React 的开发者满意度已经不及 Solid 和 Svelte。至于受关注度，React 落后于 Svelte、Solid 和 Vue，甚至已经跌破 50%。

多年以来，React 的用户满意度和关注度一直在稳步下降，采用率也停滞不前。

当然，这类调查问卷只能作为参考，在问题的表述方式上稍做手脚就能得出不同的答案。但其他同类调查也发现了类似的趋势。在 Stack Overflow 的调查中，React 的受欢迎度远低于 Svelte，仅略微高于 Vue。

有趣的是，Scott Tolinski 最近提到，他的一位开发者放弃了薪酬丰厚的 React 职位，宁愿拿一半的工资也要加入 Tolinski 领导的 SvelteKit 项目。

当然了，并不能用这个例子证明开发者连钱都愿意放弃，就为了离 React 远一点。但至少能够看出，React 带给开发者的使用感受实在称不上好。

人才供应

这方面，React 确实堪称一骑绝尘。如果想让新人快速理解之前的开发资产，那 React 的优势可太明显了。

但是吧，我觉得单这一点不足以让 React 脱颖而出。

鉴于选择 React 之后，应用程序的绑定包本身就更大、速度更慢而且复杂性更高，用这么多弊端来换取所谓项目接管期间的一点点便利，无疑是在牺牲长远收益寻求眼下省事。翻译翻译，这不就是典型的技术债务吗？

现在省下的几个礼拜，未来可能需要几个月甚至几年来偿还。所以虽然 React 在这方面占优，但大家最好还是认真核算一下，没办法无脑选它。

另外，了解 React 的朋友想上手其他前端框架，应该不是什么难事。没错，不同框架间总有一些细微差别和小怪癖，但其中遵循的设计理念还是大体相同的。任何熟悉 React 的优秀开发者，也都能在其他框架上获得同样的工作成效。

我承认，商业世界从来没有好坏，只有权衡取舍。开发速度很重要，前面提到的每一点也都很重要。所以，您的实际情况可能证明，哪怕是 React 速度更慢、绑定包更大、复杂度更高，它也仍然值得选择。是的，我都理解。

但大家做出的选择，最终也将成为与竞争对手在市场上搏杀时的一张牌。选得好就是好牌，反之亦然。如果大多数对手也选择 React，那大家就是烂牌对局、菜鸡互啄。

而如果能选得更好，也许就能压制对方的牌形。

2 批评了半天，React 为什么还是傲视同侪？

因为很多人在做选择时，往往是比较草率的。React 之所以现在受欢迎，就是因为 React 之前受欢迎。

在真正占领市场之前，人们其实是出于其他理由去选择 React 的。也许因为它能解决开发者面对的实际问题，也许因为它比较新奇有趣，或者是其他什么原因。但可以肯定的是，当时人们选 React 绝不是看中它更好就业，或者是市场普及率最高的框架。而时过境迁，现在大家再选择它，唯一的理由就是它够老、够踏实。

企业选它，因为人才市场上懂 React 的群体很大；求职者学它，是因为人才市场上企业想要招聘 React 开发者。这是个自我强化的循环，一个自我实现的预言。

于是 React 成了默认选项，只要没有充分的理由，更多人只会以无所谓的态度接着用。

while (reactIsPopular) {  reactIsPopular = true}

“毕竟没人会因为用了 React 而被解雇”，这话倒也没错。React 是个安全的选择，可能不是每个人的最爱，但至少不会惹出大麻烦。它，还是能干活的。

所以只要没有强烈的业务需求，求职者和招聘方都可以接受围绕 React 建立起来的行业现状。只要能把双方对接起来，React 的作用就已经达到了。

3 这一切会改变吗？如何改变？

我其实一直在关注事态的变化。

但要说答案，我也没有。根据之前提到的几份调查报告，React 的采用率确实出现了停滞。也不能说不再增长，只能说 React 的增长跟不断扩大的市场本体之间保持了同步，三年来份额一直维持在 80% 左右。

但终有一天，我相信这种循环会中断。但我不知道具体的导火索会是什么。

也许是个量变引发质变的过程。回想起来，很多趋势来得看似突然，但实际上一直在随时间推移而积蓄力量。也许其他前端框架更好地证明了自己，并逐渐削平了 React 在人才储备方面的优势，于是企业开始向其他方案敞开怀抱。

也可能会有部分企业触及 React 的性能上限，并结合业务需求转向性能更强的选项。比方说，如果公司的业务对移动端性能有着极高要求，而且必须能够在设备配置差、网络不稳定的区域内提供良好体验，那 React 差出的这部分性能就足以促成改变。

但对大多数企业来说，情况还没那么极端。大部分旧项目实在没必要做迁移，性能困扰虽然偶然出现，也绝不至于要因此推动大规模重构。所以继续用 React 完全没有问题，它在很多场景下已经完全够用了。

所以没准市场就固化在了这一刻，再没有谁能真正挑战 React 的统治地位。等到它真正宣布退位的时候，也许我们已经彻底抛弃了前端框架，那时候主流浏览器、特别是 JS 已经扩展到了不需要它们的地步。这就是所谓后框架时代。

还有一种可能，React 在事实上已经过时了，只是在宏观统计上还体现不出来。目前人才市场上的招聘需求，反映的是企业在很久之前做出的框架选择。正如核酸测试体现的是几天、甚至几周之前的区域内疫情状况一样，目前的招聘态势也许也存在滞后。

我不知道未来的前端会是什么样子，应该没人能做出准确的预言。但可以肯定的是，React 还能风光上好一阵子。

如果大家正在学习前端开发，想用这个为自己找份工作或提升职业水平，那 React 是个不错的选项、也是非常安全的方向。

但我也希望能有越来越多的开发者积极探索其他选项，也希望企业能给他们更多尝试的机会。近年来，前端开发领域的惊喜都来自 Vue 和 Svelte。以我个人的感受和经验，React 只是能干活，并没让工作变得更有趣。

而且越来越多的开发者也意识到了这个问题，开始尝试接触其他框架、体验它们的不同特性，也反过来意识到 React 是有多么老迈和迟钝。即使单纯从推动未来前端开发者多样性的角度出发，我也真心建议大家用用别的框架方案。

原文链接：

https://joshcollinsworth.com/blog/self-fulfilling-prophecy-of-react

点击底部阅读原文访问 InfoQ 官网，获取更多精彩内容！

今日好文推荐

Adobe 豪掷 200 亿美元收购 Figma，开发者却将其骂上了“热搜”

历时三年替换掉二十年老系统，这个团队选择“一次性到位”  | 卓越技术团队访谈录

对峙数年后，微软对 Java 的态度 180°大反转

奇葩事儿：删除用户云数据还无法恢复，只赔 3 万；微信键盘来了，体积 524MB；谷歌希望将效率提高 20%：暗示将裁员？