“开发总是选 React，扼杀了前端创新”

React 自 2013 年由 Facebook（现 Meta）开源以来，一直是前端开发领域的明星框架。它以组件化、虚拟 DOM 和声明式编程的理念迅速吸引了大量开发者，并在企业级应用和互联网产品中广泛落地。React 的出现，解决了当时前端复杂 UI 更新与状态管理的痛点，也推动了整个前端工程化的浪潮。

然而，十余年过去，前端环境和硬件性能已经发生了巨大变化。虚拟 DOM 不再是唯一高效的答案，生态中的许多替代方案——如 Svelte、Solid、Qwik——在性能和开发体验上展现出明显优势。与此同时，React 虽然依旧是默认选择，却逐渐显露出“默认惯性”的一面：招聘市场围绕 React 定义岗位，教育体系优先教授 React，团队习惯性在新项目中选择 React。这种路径依赖让创新框架很难突破，也让前端生态的多样性受到限制。

针对这种当前“凭惯性取胜”的局面，一位软件工程师 Loren Stewart 提出了批判与思考：当默认选择变成创新的阻力时，我们是否该重新审视前端框架的格局？

对于他的评价，有人认可有人反对，这一争论甚至冲上了 HN 热榜，而他究竟说了什么？我们在本文中一探究竟。

原文链接：https://www.lorenstew.art/blog/react-won-by-default/

作者 | Loren Stewart 责编 | 苏宓

出品 | CSDN（ID：CSDNnews）

默认使用 React 是有隐性成本的。下面是一个主张：在选用框架时，应当有意识地做出选择，挑选最适合的工具。

React 已不再依靠技术优势取胜，如今它的胜出更多是因为很多开发者习惯性的默认选择。但这种默认，正在放缓整个前端生态的创新步伐。

当团队需要一个新的前端框架时，讨论很少从“我们的约束条件是什么，哪个工具最合适？”开始。更多时候，话题直接落在“用 React 吧，大家都懂 React。”这种下意识的选择制造了一个自我循环，架构的决定往往不是基于技术契合度，而是基于网络效应。

与此同时，那些真有创新的框架却很难被用起来。比如 Svelte，直接把框架的开销在编译阶段就干掉了。Solid 能做到特别精细的响应式更新，而且不用付虚拟 DOM 的性能代价。Qwik 则靠「可恢复性」技术，让页面几乎能秒开。像这样的方法，在很多常见场景下都能比 React 更快更省，但往往得不到公平的比较，因为大家习惯性地直接选 React。

React 在很多方面都很优秀。问题不在 React 本身，而在于「默认用 React」的思维方式。

创新的天花板

React 的技术基础，解释了当下部分摩擦的根源。虚拟 DOM 在 2013 年是一个聪明的解决方案，但正如 Svelte 的主力开发者 Rich Harris 在《Virtual DOM is pure overhead》中指出的，它引入了许多现代编译器本可以避免的开销。

Hooks 解决了类组件的痛点，但同时带来了新的复杂性：依赖数组、闭包失效、以及被误用的副作用。甚至连 React 官方文档也在强调克制：“你可能并不需要 Effect（You Might Not Need an Effect）”。服务端组件（Server Components）改善了首字节时间（TTFB），却增加了架构复杂性和新的故障模式。

React Compiler 是一款智能的工具，可以自动化 useMemo/useCallback 之类的模式。但它的存在本身也是一种信号：我们仍在为模型里固有的约束做补丁和优化。

而与之形成对比的是其他框架的探索：Svelte 5 的 Runes 在编译期简化了响应式；Solid 的细粒度响应式可以只更新变化的部分；Qwik 的可恢复性机制则完全免去了传统的 hydration。这些并不是对 React 模型的增量改进，而是完全不同的模型，拥有不同的上限。

有创新但没人用，也解决不了问题。如果大家只是习惯性地选一个框架，那新的东西根本没机会被采用。

我们共同背负的技术债

默认使用 React，往往意味着我们无条件接受它的运行时和协调成本。即便在很多情况下“够快”，它的上限依然低于编译期或细粒度模型。开发者花费大量时间在管理重新渲染、Effect 依赖、hydration 边界上，而不是在交付业务价值。性能研究给出的总体结论是一致的：JavaScript 在关键路径上代价高昂。

更深层的问题在于，我们的思维模型围绕着“React 模式”为中心，而不是以 Web 基础为中心，这降低了技能的可迁移性，也让架构惯性更容易固化。

损失的不仅仅是性能，还有当更合适的替代方案从未被评估时的机会成本。比如，在JS Framework Benchmark这样的基准测试中，Solid 在响应式密集的场景下，更新速度往往比 React 快 2–3 倍。

被压制的框架们

Svelte：编译器革命

Svelte 把大量工作前移到编译期：没有虚拟 DOM，运行时开销极小。组件最终被转化为针对性的 DOM 操作，思维模型也更贴近 Web 基础。

然而，“缺乏足够的岗位需求”让 Svelte 的采用率被人为压低，即使在大多数用例里它有更突出的技术优势。真实案例已经证明它的价值：例如 The Guardian 在前端中引入 Svelte 后，性能和开发效率都有显著提升，打包体积减少，加载速度加快。再比如外媒 Wired 的报道提到，开发者 Shawn Wang（X/Twitter 上的 @swyx）将自己的网站从 React 的 187KB 缩减到仅 9KB，正是依靠 Svelte 的编译期优化，把框架开销从运行时剥离。这种机制让应用在慢速网络下也能更快、更高效。

Solid：响应式原始方法

Solid 提供细粒度的响应式，并保留了 JSX 的熟悉体验。更新通过 signal 直接流向受影响的 DOM 节点，完全绕过协调（reconciliation）的瓶颈。它具备强劲的性能特征，但知名度有限。

根据 Solid 的官方对比指南，这种模式比 React 的虚拟 DOM 更新更高效，响应式更精准，避免了不必要的计算，同时也让状态管理更简洁，改善了开发体验。

虽然与更成熟的框架相比，Solid 的典型案例还不算多，但这主要源于采用率偏低。来自早期用户的反馈显示，它能带来更新效率和代码简洁性的显著提升，只待更多团队尝试和扩展，才能得到更广泛的验证。

Qwik：可恢复性的创新

Qwik 采用可恢复性（resumability）而不是 hydration，让应用只加载当前交互所需的内容，从而实现即时启动。这对大型站点、长时间会话或慢速网络尤为理想。根据 Qwik 的 Think Qwik 指南，它通过渐进式加载以及状态与代码的序列化来实现应用恢复，无需繁重的客户端初始化。结果是具备更好的可扩展性和更短的初始加载时间。

Qwik 的成功案例之所以相对少见，很大程度上是因为很少有团队愿意跳出默认框架去尝试。但那些尝试过的团队普遍报告了启动时间和资源效率的巨大提升，这意味着它还有大量潜力尚未被释放。

这三个框架之所以“被低估”，并不是因为技术不够优秀，而是因为“默认选择”阻碍了它们的试用。

此外，React 的 API 接口比这些替代方案更庞大、更复杂，包含 hooks、context、reducers、memoization 等概念，开发者必须小心管理才能避免陷阱。这种庞大的 API 带来更高的心智负担，常常导致依赖理解错误或过度设计，从而引发 bug。比如在 2025 年 9 月 12 日 Cloudflare 的一次宕机中，一个带有问题依赖数组的 useEffect hook 触发了反复的 API 调用，压垮了他们的 Tenant Service，造成大面积故障。相比之下，Svelte、Solid 和 Qwik 的 API 更小、更聚焦，强调简洁和 Web 基础，降低了开发者的心智负担，也更易于掌握和维护。

网络效应的囚笼

React 的主导地位制造了自我强化的壁垒。招聘信息往往写的是“招聘 React 开发者”，而不是“招聘前端工程师”，限制了技能的多样性。组件库和团队的习惯进一步加固了这种惯性。

风险规避型的管理者会选择“最安全”的选项。学校教授市场所需的技能。于是，这个循环在技术优劣之外继续运转。

这不是良性的竞争，而是由“默认”造成的生态垄断。

打破网络效应

要逃离这个困局，需要在多个层面主动出击。技术负责人应当基于约束条件和技术优势来选择，而不是凭借惯性。公司可以预留一部分创新预算来尝试替代方案。开发者则可以拓展技能，不局限于某一种思维模型。

教育者可以在教授具体工具的同时，加入与框架无关的概念。开源贡献者则能帮助替代生态逐步成熟。

改变不会自动发生，它需要有意识的选择。

框架评估清单

如果想做出有意识的选择，可以在启动新项目时参考以下简要清单：

• 评估性能需求：考量启动时间、更新效率、打包体积等指标。如果速度至关重要，应优先考虑具备编译期优化的框架。

• 团队技能与学习曲线：结合现有经验，同时考虑迁移路径；许多替代框架提供平滑过渡（如 Solid 与 React 兼容的 JSX）。

• 扩展性与长期成本：计算长期开销，包括维护、依赖管理和技术债。替代框架通常减少运行时开销，降低托管成本，并改善可扩展性。

• 生态系统适配度：在成熟度与创新性之间寻找平衡；可以先在非关键模块中试点，验证迁移的可行性和投资回报。

常见的反驳理由

有人可能会找各种理由来拒绝新框架，比如：

• “但是生态不够成熟！”

其实成熟的生态固然有价值，但也可能加深开发者的惰性。年头长不等于适合今天的约束。成熟生态往往意味着对第三方包的高度依赖，这会带来额外维护成本：需要不断更新依赖、应对安全漏洞，甚至因未使用的代码而导致打包膨胀。

虽然有时不可避免，但这种灵活性可能导致过度依赖；相较之下，基于具体需求的定制化方案往往更轻量、更易维护。小而新的生态鼓励从基础出发，减少技术债，并加深对底层的理解。而且随着 AI 编码助手能按需生成精准的定制函数，构建轻量的应用专用工具库已比以往更容易，像 lodash 或 Moment 这样的通用库很多场景下可以完全避免。

• “但是招聘难！”

招聘随需求而动。可以先在非关键路径试点替代框架，以此降低风险，再通过招聘基础扎实的开发者并提供上手培训来填补技能差距。

• “但是缺少组件库！”

框架无关的设计系统和 Web Components 能减少锁定，同时保持开发效率。

• “但是 React 更稳定！”

React 从类组件到 Hooks，再到 Server Components，本身就是不断变动，而非稳定。许多替代框架反而提供更一致的 API。

• “但是它经过规模验证！”

jQuery 也曾在大规模中被验证，但过去的成功不保证未来的相关性。

更广泛的生态损害

当一个框架的限制变成事实上的天花板时，单一文化会拖慢 Web 的演进。人才花大量时间解决框架特有的问题，而不是推动平台前进。投资也会无视技术优劣，只跟随既有霸主。

课程更关注“立即就业”而非基础知识，培养出的是框架专属技能，而非可迁移的能力。平台改进也因此被延后，因为“React 可以搞定”成了默认答案。

当多样性消失，整个生态都在受损。

我们可以做的事情

健康的生态需要多样性，而不是单一文化。真正的创新来自不同方法的竞争与交融。开发者通过学习多种思维模型而成长；当多个框架在不同方向上推进边界时，平台也会更快进步。

把所有赌注压在一种模型上，就等于制造了单点风险。一旦它遇到硬性瓶颈会怎样？我们又错过了多少本该探索的机会？

是时候回到约束与技术优劣，而不是靠着单一的个人、团队使用习惯来选择框架了。你的下一个项目，理应得到比“默认 React”更好的方案。整个生态，也理应获得只有多样性才能带来的创新。

不要再默认种下同一颗种子。通过多样化框架探索，我们本可以培育出一个更具韧性、更具创新力的花园，而不是滑向单一化的荒地。选择权，就在我们手中。