“应该禁止所有新项目使用 React！”微软资深工程师犀利 diss：“React 是行业标准”简直胡说！

“框架主义终究无法实现。正确的答案不是再搞出新的工具，而在于具备大刀阔斧进行工程设计的勇气。”有着十多年经验的软件工程师 Alex Russell 在他最近《React 不行，那到底什么行》的博客中提到。他在文中直接了当地表示，“如今任何人都不该用 React 构建新项目。”这篇博客迅速引起了开发者们的关注，并展开了一场围绕 React 的激烈讨论。

有开发者赞同 Russell 的观点：可能许多开发者都不知道如何在没有 React 的情况下构建东西。他们对 html、服务器端渲染、渐进增强或 React 出现之前我们用来构建数据应用表单的任何东西一无所知。更糟糕的是，这影响了整整一代人。当然，也有很多开发者反对他的观点，理由也很多，比如对于性能问题，有开发者表示前端性能问题几乎从来都不是最紧迫的问题等。

值得一提的是，Russell 是微软 Edge 团队的合作伙伴项目经理和 Blink API 的所有者。在 2008 年到 2021 年的 13 年间，他在谷歌担任软件工程师，从事 Chrome、Blink 和网络平台的工作。Russell 曾是 Chrome 的第一位网络标准技术领导（2015-2021 年），并且是 W3C 技术架构组的三届当选成员（2013-2019 年），以及十年的 TC39 代表。我们翻译了这篇文章，并在不改变作者愿意地基础进行了调整，以飨读者，以下为译文。

过去这十年来，我的主要工作就是通过团队合作，为桌面和移动设备构建雄心勃勃的 Web 类产品。在此期间，我也得以近距离观察过百个项目所涉及的各色团队、产品和技术栈。

虽然我也希望能把更多时间花在改进 Web API 上，但之前跟合作伙伴一起做的主要是修复由“现代”前端框架（例如 React、Angular 之类）及其相关文化引起的性能和可及性问题。必须承认，这些问题在当今基于 React 的技术栈中已经相当明显。

在我看来，作为一项遗留技术，React 在全新应用程序中的普遍存在着实令人不安。

更令人惊讶的是，有些人坚持认为 React 具备“现代性”。我倒是觉得 React 的这种“现代性”跟所谓“现代艺术”颇有几分相似——既没有体现出现代设计，也跟现代技术没半毛钱关系。它们并非为了满足当前需求或者性能标准而出现，纯粹只是一种成本高昂、能让人们回想起上个时代陈旧观念的集合体。

为了帮助更多团队避免“踩雷”，我想通过这篇长文提醒各位管理者和开发人员清晰意识到这种所谓“前端正统观念”的错误与危害。

简而言之，2020 年代了，任何人都不该用 React 构建新项目。

引发失控的文化

在服务器上运行的代码有着明确的成本计算方式。服务器端系统的性能和可用性由配置部门进行控制，延迟则由开发人员和 DevOps 工程师们主动管理。

相比之下，在客户端上运行的代码则纯由计算机本身决定。期间出现的一切延迟、客户端资源不足甚至是 API 功能都不在开发者的控制之内。

客户端 Web 开发应该是最典型的面向影响编程。就是说一旦代码离开数据中心，Web 开发人员就只能祈祷一切平安无事、再无插手的余地。

于是乎，一种不合理但有效的策略就强调尽量减少发出的代码。实际上，这意味着优先使用 HTML 和 CSS 来替代 JavaScript，因为前两者可以更优雅地降级并具有更高压缩率。声明式表单每发送一个字节都能生成更多功能性 UI，由此带来的弹性改进与成本降低将在网站的整个生命周期内发挥积极作用。

基于 React、Angular 及其他面向遗留系统，而且以桌面为中心的 JavaScript 框架，其技术栈则往往采取截然相反的做法。这类生态系统嘴上总说，“种种控制措施是为了防止不必要的客户端垃圾大量扩散所设立，”但由此带来的后果就是 NPM 合并的包充满了冗余，例如 core-js、lodash、underscore、不再存在的浏览器 polyfill、用户空间 ECC 库、moment.js 以及其他更多让人头痛的杂项。

这种文化必然引发失控，以至于 2024 年的 React 开发人员似乎也无法在不招惹这些遗留内容的前提下构建聊天机器人， 甚至还在使用非常笨拙的 MathML 或者 TeX 格式库来显示公式——而这一切，都只在极少数的会话中才被用到。

技术负责人和管理者应当打破这种魔咒，强制推动有益于客户的决策。换言之，直接禁止在所有新项目中继续使用 React。

那接下来怎么办？

这个问题看似简单，但却需要分成两个部分来看待：

狭义形式：“假设我们对客户端渲染仍拥有充分需求，那应当使用哪些特定技术来代替 React？”
广义形式：“我们的产品技术栈一直依托于 React，很多开发者也一直认定 React 是 Web 开发领域的‘银弹’。如果要求重新规划设计，那我们该选择哪种新的‘银弹’？”

对于其中的狭义部分，相信具备适当产品决策的团队都能通过客观的测试来找到答案。比如建立多个小型概念验证项目来确定各种方法的影响因子与限制条件。这就是工程学的魅力所在，先充分理解约束条件、再尝试新方法以改善用户感受。

注意：构建 SPA 或者客户端交互岛的开发人员已经有很多选择，因此本文不会推荐特定工具。简单来讲，Svelte、Lit、FAST、Solid、Qwik、Marko、HTMX、Vue、Stencil 等数十款当代框架都值得一试。

尽管它们的初始成本较低，但实际投资任何一款都需要注意严格控制客户端的有效负载和复杂性，毕竟按照字节计算，JavaScript 的成本仍然相当于等效 HTML 和 CSS 的 3 倍以上。

相信大家也感受得到，近年来技术栈决策面临的实际限制已经发生重大变化，至少是跟网站用户群乃至产品经理 / 技术主管的预期大不相同。收集这类数据有助于对技术栈进行初步筛选，快速提取出部分更具价值的选项来运行和比较。

但耗费时间和精力最多的，还不是这个环节。

很多人会问，“如果 React 不行，那到底什么行？”他们自以为问的是狭义形式，但实际上是在努力解决广义问题。更令人震惊的是，相当一部分积极且充满善意的产品经理和工程师们并没有认真关注过所使用架构的具体细节，而是随大流地选择了人气最高的架构。

对一部分人来说，放弃 React 会让他们突然没了依凭，不知道自己要以怎样的方式理解前端世界。身陷这种困境的团队开始审视自己的价值观和决策认识论，比如要如何判断自己的技术选择比其他人好？他们为什么要选择某项技术，而非其他方案？

很多人对自己的理解没信心，必须要辅以“行业权威”之类的证明。于是框架主义就成了当今前端领域的主导信条，其坚持认为只要团队努力构建框架，一切用户问题都将迎刃而解。但这明显不合逻辑，甚至可以说是本末倒置。实际上，让 Web 体验变好的唯一方法就是关注用户体验——具体来讲就是关注边缘用例的体验。技术方案总是来了又去，而起到决定性作用的永远是谁更关注用户感受。

所以 真正的难点，在于说服管理者和技术主管，让他们更多从用户的需求出发。Public Digital 曾对这一点做出很好的总结，“为用户需求做设计，而不是为组织便利而设计。”

这种思维转变的基本要素，就是用基于研究和证据的约束条件取代假大空的承诺。这也更多回归了工程设计的本质——即在已知的约束条件之下，为用户和社会设计出具有实践意义的解决方案。

而工程思维的反面，就是假定不存在约束条件或者你的产品不受约束，而这简单总结就是“纯纯意淫”。

但拒绝这种根深蒂固的观念并不容易。框架主义所宣扬的用户体验改善思路，是在框架的生态系统中引入更多（或者不同）工具。这在表面上看似乎很符合工程思维，但事实却并非如此。其甚至成了一种宗教式的承诺，导致框架主义者渐渐失去在框架之外主动寻求解决方案的习惯和能力。

在他们眼中，能够为用户带来重大收益的非传统模式反而成了需要被消除的错误。而如果没有数据或者证据来抵消意淫者的粗暴论断，又有谁能说他们真的错了？于是脱离量化结果的传统观念在传播中继续被歪曲和玄学化，而踏实可靠的实践却被视为异端而遭受严厉制裁。

这，就是荒谬的现实。

现实主义者当然不会沉溺于玄学，他们会尝试对一切做量化。现实主义者关注世界的本来面目，而不相信自己直觉中的样子。从这个意义上讲，现实主义与框架主义成了一对截然矛盾的反义词。

打破这种魔咒最有效的方式，就是让管理者重新以用户为中心来看待系统技术。 比如采用 Rum 数据的形式，例如核心 Web 生命力（https://web.dev/articles/vitals）或者由经过良好配置的测试台（例如 WPT，https://webpagetest.org/）提供的实验室结果。检测关键用户旅程并讨论业务的目的在于快速跟进动向，保证团队能够把握趋势并制定出切合变革方针的业务案例。

Rum 和基准数据源堪称框架主义的“解毒剂”，因为它们能够切实提供由数据驱动的基准素材。掌握数据的团队可以借此权衡盲目行动所带来的实际成本与潜在回报，而不是单凭直觉就贸然投资于某种新的框架。

拒绝 React 并不会造成价值损失

而且通过强制政策来禁止 React（或者其他框架主义倾向）则会带来惊人的成本节约效果，让团队重新回归为用户交付优秀成果的轨道。

而从广义角度入手，这个问题的答案可以分为以下几部分：

用户关注：决策者必须直接对其工程选择负责，不可推卸责任。必须将表现不佳的系统替换为表现良好的版本。任何事物不应存在神圣光环，且必须辅以适当约束才能解决问题。
证据：管理层和工程部门间的共同承诺，是落实现实主义的必要前提。重视证据，重视客观现实。
护栏：通过政策消除出于直觉的框架主义判断。组织当然可以根据需求调整指导方针，但最重要的是先设置一项基准。
测试：没有明确的指标支撑，就不应部署任何瓣系统。这些指标体现的是用户在系统中的期望行为。只有掌握了这些定义，我们才能开展测试，探索各种系统交付情况。在这样的健康流程下，产品经理的角色才会更加鲜明。他们需要定义产品价值锚点并将其与成功融合起来，而不能只是进行无休止的实验。

现实主义和框架主义的差异

要了解现实主义和框架主义在实践中的差异，我们不妨从实例入手。回想起来，我们选择技术的标准往往围绕着对主要数据（更新）的操作次数和会话长度展开。某些类型的用例天然拥有更长的会话和对 UI 主要信息的频繁增量更新。虽然也不乏例外，但一般来说平均会话较短的站点无法承受太多的 JS 前期投入。