【译文】React 是新的 IBM

React| 2024-02-28

我们这些从业时间足够长的人看到过这句话的各种变体来来去去：

从来没有人因为挑选 IBM 而被解雇(意思是：虽然不是最好的，但很安全)

谷歌搜索结果的第一条就是一篇关于这个问题的精彩博文：

[它]是一句未注明出处的名言，在科技圈中被频繁重复，以至于很多 IBM® 的长期用户都深信不疑。

这是一个进步的问题。

这是一种维持现状的心态，是纯粹创新的最大敌人。

这种说法的变种层出不穷；把 “IBM “换成 “甲骨文”、”微软”、”英特尔 “或 “SAP”，你就明白了。

虽然 React 显然不是一家公司，但我想说，React 现在拥有同样的头衔：它是进步的问题，是现状思维的症状。

web前端现状

2022 年前端开发现状调查不出意外地显示，React 的使用率仍居首位。事实上，它的市场份额还在继续增长（至少在本次调查的有限受众中是如此）：

React 的使用率实际上在上升；很可能与 Next.js 的增长有关。

如果我们用 YCombinator 的 “Work at a Startup “招聘网站作为初创企业世界的代表，你会发现它更偏向于 React：

现在，Target 等大型物业也在使用它：

使用 Next.js 的 Target 网络公司

还有沃尔玛

使用 Next.js 的沃尔玛网络公司

没有比 React 更明确的信号了，它现在是 “安全 “的选择–现代的 IBM，这就是为什么你可能不应该选择它的原因。

React 的问题

性能

在 React、Angular、Vue、Svelte 和 Preact 等主要前端库中，React 是性能最差的库之一。

无论从有效载荷大小还是从性能上看，React 都是最差的库之一：

或 CPU 时间：

React 的表现非常糟糕。

主要 UI 库的基准测试一致显示 React 的性能很差：

执行时间

几乎涵盖了所有有意义的性能方面：

内存分配

React 的有效载荷大小小、执行速度慢、内存消耗大，这一切都使它成为面向移动用户的网络应用的不二之选。

生态系统与创新

尽管如此，React 仍然是前端开发的顶级库。

部分原因在于它是一个自我实现的预言的副产品，这与 IBM 或微软占据主导地位的时代并无二致：选择 IBM、微软、甲骨文或 React 的生态系统和所认为的 “安全性 “创造了一个自我喂养的循环，即更多的 React：

while (react.isPopular) {
  react.isPopular = true
}

但这造成了一个盲点：创新。

你看：生态系统越大，依赖性越强，创新的难度就越高。这不仅仅是为了创新而创新，而是为了提高性能、改进 DX、改善最终用户与现代网络应用的交互体验。一旦某个派别获得了 React 这样的市场主导地位，创新就必然会被淘汰。

还有比这更 “现状 “的吗？

当我第一次看到Andrew Clark的推特时，我以为这是个玩笑。这肯定是在开玩笑，对吧？

“但我更喜欢 React 的模式，即每次都假装整件事都是重新创建的。

但这并不是玩笑；事实上，尽管有证据表明存在更好、更快的模式，React 团队还是会加倍坚持这种方法，因为该团队首先受制于其市场份额，同时也过于自大，不敢承认他们一直在向我们–开发者和最终用户–推销柠檬。

正如亚历克斯-拉塞尔（Alex Russell）在他的评论文章中写道的那样

柠檬市场依赖于客户比销售伪劣产品的人掌握更少的信息。有些人在早期对这些堆栈大肆宣传，但其实他们是无知的，当认识到错误导致行为改变时，这种无知是可以原谅的。但过去十年中最流行的框架并非如此。

安德鲁-克拉克（Andrew Clark）希望使用更多的编译器魔法来解决 React 的缺陷，这的确是一种非常脸谱化的方法来解决性能和底层技术模型的适用性问题。我们在 HipHop 虚拟机（为大规模解决 PHP 问题而创建）和 Hack 编程语言中也看到了同样的做法。

一方面，我认为我们应该赞扬 React 团队，因为他们确保了在 React 上投资的团队不必从头开始折腾（就像他们能够通过 HipHop 扩展性能不佳的 PHP 一样）。然而，另一方面，我们也可以看到，React 失败的解决方案是通过将更多的 “魔法 “强加给编译器来使一个残缺不全的模型正常工作，从而进一步偏离构建 Web-UI 的渐进方法。

在我看来，React 显然是一条死胡同，其根本缺陷只能通过编译器魔法来解决。我们在这里构建的是 JavaScript 和 HTML 前端，而不是操作系统！

复杂性

与昔日的 IBM 大型机系统和微软的企业软件一样，这类系统的复杂性被严重低估。这就是处于主导地位和成为 “安全 “选择的部分原因：市场份额造成了一种错觉。

亚历克斯-罗素（Alex Russell）的文章再次直截了当地指出：

复杂性商人（complexity merchants）知道他们所处的环境并不典型，但他们却把高度专业化的工具当作普遍适用的工具来销售。他们知道，大多数网站缺乏严格的延迟预算、专门的性能团队、鹰派的管理审查、防止倒退的 “出货门”，以及对关键用户旅程的端到端测量。他们明白，要扩展 JS 驱动的前端，唯一的办法就是在控制复杂性方面进行大规模投资，但他们却没有警告任何客户。

他们本可以坦然承认错误，承认这些技术需要庞大的基础设施才能运行；除了最成熟的团队外，其他团队都无法扩展这些技术。但他们却反其道而行之，年复一年地加倍努力，气喘吁吁地发布虚有其表的产品，以阻止对根本设计缺陷的批判性思考。他们还在幕后努力排挤那些指出令人不安的结果和超常成本的人。

React 的复杂性被很好地隐藏起来，但这是呈现周期中无状态组件假设所固有的，这意味着开发人员需要了解何时何地谨慎地放置状态。

React 的功能模型对状态管理的难度做出了某些假设，而我认为这些假设并不正确。World of BS 简明扼要地介绍了不同的编程理念以及它们是如何看待状态的：

我最近意识到，所有不同的编程理念都与状态有关，而且可以归结为如何处理状态的简单陈述。

面向对象 – 同时修改大量状态很难做到正确；将状态子集封装到单独的对象中，并允许通过方法对封装的子状态进行有限的操作。

功能型 – 修改状态很难保证正确性；应将状态保持在边界内，并保持逻辑的纯粹性，以便更容易验证逻辑的正确性。

那么，React 的功能性方法是否降低了状态正确性的复杂性呢？

如果您发现自己的代码中存在错误的副作用，并在发现 UI 中存在奇怪的 bug 后添加了 useMemo 和 useCallback，那么欢迎您加入这个俱乐部。如果考虑到每个有状态 UI 应用程序库或框架（无论是桌面应用程序、移动应用程序还是 3D 游戏库等）的设计方式，React 的呈现模型和对功能纯粹性的坚持就有悖常理了。

没错，在底层，显卡会逐帧绘制，丢弃之前的像素缓冲区，但这只是底层的实现细节，而抽象意味着这些底层细节不会影响到开发人员，我们通常总是假设我们的组件或对象是有状态的。换句话说，虚幻、Unity 或 Godot 等引擎的目的就是通过抽象来提高工作效率。

也许，Facebook 要求 React 开发人员每次都假装 DOM 树是重新创建的（而事实上不是）是有原因的 🤷‍♂️。

这就引出了我的下一个问题：

它无法解决你的问题

我承认，React 的初始学习曲线非常低，因为 React 本身主要关注的是简单的渲染和最基本的状态管理。即使你的 React 做得不好（例如没有编写 “纯粹的”、无副作用的组件），你也很少会注意到其中的问题。

然而，React 在状态改变时重新创建 UI 的逻辑模型在大规模应用中却很难做到正确。我的意思是说，随着应用程序和团队规模的扩大，由于技术水平、知识和经验的不同，以及代码量的增加，编写带有副作用的组件的几率也会增加。

对于 Facebook 和 Target、沃尔玛这样的大型企业团队来说，通过严格的测试、额外的工具和更好的培训，这种情况也许是可以控制的。那么问题来了，React 是否是初创公司或希望快速发展的小型团队的最佳工具？我认为答案是 “不”；React 诞生于 Facebook，旨在以 Facebook 的规模和资源解决 Facebook 的问题。

从某种意义上说，这让人想起斯科特-凯里（Scott Carey）的文章《复杂性正在扼杀软件开发人员》（Complexity is Killing Software Developers），其中有这样一段精彩的论述：

“必不可少的是你所从事的业务领域的复杂性，事实上，企业是一个极其复杂的环境，因此他们试图解决的问题本身就很复杂。另一个方面是偶然性；这是我们的工具带来的复杂性，也是我们在解决问题时在上面叠加的东西。”

Carey 特别指出，从单体方法到微服务的转变是现代架构复杂性的主要来源之一。

当然，微服务有其存在的理由和时机，以及随之而来的复杂性，但每个团队都需要问自己一个问题：”我需要这样做吗？

Jason Warner–前 GitHub 首席技术官对微服务的看法。

就像 React 的复杂性一样，答案很可能是 “否”；我们中的大多数人并没有使用 Facebook 或 Target 或沃尔玛规模的资源来解决 Facebook 或 Target 或沃尔玛规模的问题，而是选择使用 Facebook 或 Target 或沃尔玛级别的黑客和变通方法。

对于我们中的其他人，尤其是初创企业来说，能够快速行动而不自乱阵脚可能是选择技术堆栈的更重要方面。

用户界面领域的大部分创新现在都发生在 React 生态系统的边缘： Solid.js, Preact.js, Svelte.js, Vue.js, Astro.js, Qwik.js, Marko.js, 并利用现代 JavaScript 功能逐步增强。

就像 IBM 一样，React 终有一天也会因为自身的庞大规模和无法创新出更好的解决方案而失去王位。从 React 团队如何看待前端的现状，以及如何继续（而不是）改善开发人员、团队和终端用户的体验，这一点已经显而易见。Vue 的 Evan You 从其他团队借鉴更好的想法（例如 Vue 即将推出的 Vapor 模式）没有任何问题，而 React 团队尽管承认有更好的性能模式，却只是一味地加倍努力！

React 是新的 IBM：你应该学习它，了解它的缺点，也许你还应该部署它。你永远不会因为选择它而被解雇，但它将是昂贵的、臃肿的、难以做好的，而且在实施过程中的每一步都将是无趣的。React 是 “维持现状的思维模式–纯粹创新的最大敌人”。

本文文字及图片出自 React is the New IBM