React 曾是前端开发界的明星框架，凭借其高效的组件化开发方式，迅速赢得了开发者的青睐。然而，随着时间的推移，React 在许多开发者眼中逐渐失去了昔日的光辉。

继今年 7 月，微软宣布不再在 Edge 浏览器中使用 React 之后，现任 Microsoft Edge 合作伙伴项目经理 Alex Russell 于近日发布了一篇主题为《如果不是 React，那该用什么？》的长文，其直言不讳地表示，“在 2020 年代，不应该再有人基于 React 开始新的项目。” 

他认为，框架主义未能如预期般提升开发效率和用户体验，反而带来了更多不必要的复杂性和性能问题。至于用什么来替代这门框架，他强调，真正的解决之道并不是换一个工具，而是要有勇气去做真正的工程。

React 本应简化开发流程，但如今因为过度依赖框架和组件化思维而备受争议。在这种背景下，React 是否仍是前端开发的最佳选择，值得我们重新审视。接下来，我们将从 Russell 的文章中深入了解他的最新观点。

原文：https://infrequently.org/2024/11/if-not-react-then-what/#fn-rubrics-9

作者 | Alex Russell   编译 | 屠敏、郑丽媛出品 | CSDN（ID：CSDNnews）

以下为译文：

在过去的十年里，我的工作重点是与团队合作，共同开发面向桌面和移动端的 Web 产品。这让我有机会近距离接触了各种各样的团队、产品和技术栈，回顾过往，我参与了超过 100 个项目。

虽然我个人更希望将大部分时间专注于改进 Web API，但往往事与愿违，与合作伙伴们的合作大多数时间都用于解决由“现代”前端框架（如 React、Angular 等）及其周围文化所带来的性能和可访问性问题。这些问题在基于 React 的技术栈中尤为突出。

这令人不安，因为 React 已经被很多人视为是一门过时的技术，但它依然出现在新建的应用程序中。

不过，也有一些人仍然坚持认为 React 是“现代”的技术框架。也许在今天这篇文章里，我们可以通过理解“现代”一词来解释这种情况，就像它在艺术中应用一样。React 和艺术作品一样，并没有展示当代的设计或构建技术。它们并非为了满足当前的需求或性能标准而构建，而是基于过去的过时方法，并且在那个时代这些方法曾经是最先进的、最昂贵的。

为了让更多的团队远离使用 React 带来的后续困境，我基于最新的研究，分析当前的局势，同时通过讲座提醒管理者和开发人员注意当前前端正统观念的危害。

简而言之，在 2020 年代，不应该再有人基于 React 开始新的项目。这一点无须质疑。


客户端复杂性最小化原则

在服务器上运行的代码完全计算出成本。服务器端系统的性能和可用性由提供服务的组织控制，延迟性则可以由开发人员和运维工程师主动管理。

相比之下，运行在客户端的代码则是在“魔鬼的计算机”上运行。用户所体验到的延迟、客户端资源，甚至可用的 API，都不在开发人员的控制范围之内。

客户端 Web 开发或许最好可以将其理解为一种面向影响力的编程方式。一旦代码离开数据中心，Web 开发人员能做的只是祈祷和希望。

因此，一个出奇有效的策略是减少代码量。实际上，这意味着开发者可以优先使用 HTML 和 CSS 而不是 JavaScript，因为 HTML 和 CSS 更加简洁，并且在压缩时能有效减小文件大小，同时也能优雅地在不同条件下降级工作。声明式编程的方式能够让开发者通过发送较少的字节来实现更多的功能性界面（UI）。这些优化不仅能提高网站的稳定性（韧性），还能降低开发和维护成本，而这种效果随着网站使用时间的增长会成倍放大。

基于 React、Angular 和其他一些遗留的、面向桌面的 JavaScript 框架的技术栈，通常采取的做法与上述的减少代码量的策略相反。虽然这些生态系统口头上承诺要防止不必要的客户端代码过多，但实际上，它们往往会通过 NPM 包的合并，导致代码中包含了大量冗余的库和代码，比如 core-js、lodash、underscore、为已不存在的浏览器提供的 polyfill、用户空间的 ECC 库、moment.js以及其他一百个类似的复杂库。这些冗余的代码和库不仅增加了文件的体积，还可能带来不必要的性能负担。

如今这种情况已经进入失控状态，似乎 2024 年的 React 开发者在构建聊天机器人时，根本无法不包括那些 2010 年代的遗留库，甚至还要再加上至少一个非常笨重的 MathML 或 TeX 格式化库来显示公式，事实上，这种需求只会在极少数会话中才会出现。

当前，公司的技术主管和经理们需要打破这种魔咒，深入了解自己所做的决策对客户端性能、效率和用户体验的实际影响，承担起更多关于客户端技术决策的责任。实际上，这意味着在所有新的工作中禁止使用 React。


好吧，那又该怎么办呢？

禁止使用 React 这个问题有两种解读观点，值得仔细区分：

狭义形式：“假设我们确实需要客户端渲染，你会推荐哪些具体技术来替代 React？”

广义形式：“我们的产品栈已经选择了 React，并且接受了那些在以 React 为中心的播客中讨论的各种神话。你现在要求我们重新思考整个架构。我们该选择哪种灵丹妙药代替 React？”

那些做出正确产品决策的团队，可以通过客观的实验对比，解决上述狭义上的问题。具体来说，团队可以通过构建多个小规模的概念验证（PoC）来测试不同方法的可扩展性和局限性。这种做法不仅有效，而且很有趣，因为它允许团队在明确的约束条件下尝试新技术或方法，从而改善最终的用户体验和结果。

注意：构建 SPA（单页应用程序）或客户端交互性模块的开发者有很多选择。这篇博客不会推荐具体的工具，但 Svelte、Lit、FAST、Solid、Qwik、Marko、HTMX、Vue、Stencil 等以及其他数十种当代框架都值得关注。

尽管它们的初始成本较低，任何投资这些框架的团队仍然需要对客户端负载和复杂度进行严格控制，因为 JavaScript 的成本至少比同等 HTML 和 CSS 高出 3 倍（按每字节计算）。

毋庸置疑，技术栈的决策标准会随着时间的推移而发生变化。可能是因为上次审视技术栈时的条件发生了显著的变化，或者是网站的用户群体和产品经理、技术主管预期的用户群体之间差距很大。因此，收集相关数据来了解这些变化，可以帮助团队在做第一次决策时更快速地缩小选择范围，为后续的比较实验提供更有针对性的依据。

但我们花最多时间接触的团队并不处于这种位置，也不会做上述这些事情。

很多人在问“如果不使用 React，那用什么？”时，认为自己是在问狭义的问题，但实际上他们正面临广义问题。令人震惊的是，很多（有能力、出于善意的）产品经理和工程师没有深入思考架构的原因和背景，而是选择跟随潮流。

对于一些人来说，放弃 React 这种流行的技术框架，会让他们感到迷茫，甚至怀疑自己是否还能理解这个世界。处于这种状态的团队，面临的是关于技术选择和价值观的认知危机。他们不确认如何判断自己的技术选择是否优于其他选择，也不知道为什么会选择这个技术栈而不是另一个？

很多人需要帮助去找到更合适的方法来解决前端问题。如今，框架主义（即依赖使用框架来解决问题的思想）已成为前端开发的主流理念。持有框架主义的人认为，只要团队足够努力地使用某个框架，所有的用户问题都会得到解决。然而，这是逻辑错误，甚至可以说是完全错误的。事实上，唯一能使 Web 体验变得好的是关心用户体验——特别是边缘用户的体验。技术来来去去，但始终能带来差异的，是关心用户。

通俗地说，这场斗争最具挑战性的地方在于说服经理和技术主管，让他们从用户需求出发。正如全球知名咨询公司 Public Digital 所言，“为用户需求设计，而非为组织便利设计。”

要做到这一点，需要改变思维方式——从单纯依赖承诺和想象，转向基于实际的研究和证据来做决策。这与所谓的“无所不用其极的工程”相吻合，因为工程的本质是利用已知条件和限制，为用户和社会创造切实可行的解决方案。

与之相对的是一种不切实际的幻想——认为没有约束条件，或者认为那些限制根本不适用于你的产品。这种想法用一个词总结就是“胡扯”。

现实中，要拒绝根深蒂固的“胡扯”做法并非易事。所谓的“框架主义”宣扬，改善用户体验的方式是采用更多（或不同）的框架生态工具。乍一看，这让信奉者有事可做，看起来像是在进行工程实践，实际上并非如此。这种做法甚至让人深信不疑，只关注框架生态内部的解决方案，而忽视框架之外更实际、更有效的选项。如果有一种非主流的方式对用户更有帮助，“框架主义者”可能还会把它当成错误去排斥。更糟的是，如果没人拿出数据和证据来反驳这些错误做法，就很难证明它们的问题。结果，忽视用户需求的做法会越来越荒谬，而质疑这种做法的人反而可能被视为“异端”，甚至被打压。

说白了，这一切都是“胡扯”。

现实主义的做法和框架主义正好相反。现实主义者不会沉迷于那些看似高深的概念，而是用数据和事实来评估用户体验。他们关心的是真实情况，而不是理想化的假象。

要打破框架主义的迷思，最有效的工具就是为管理层提供真实的、以用户为中心的系统表现数据。比如，可以使用 RUM（真实用户监测）工具，像 Core Web Vitals 来分析网页性能；或者通过实验室工具（比如 WPT）获取具体的测试结果。同时，监测用户的关键行为路径，把这些数据和业务目标结合讨论，也能更快推动改变。

像 RUM 和其他基准数据，能帮助团队摆脱盲目追逐框架的陷阱。因为数据能清楚显示：引入这些框架到底花了多少成本，实际能带来多大的回报。只有用数据说话，才能让团队做出真正理性的决策，而不是盲目“信仰”某些框架。