默认选择 React，等于是在扼杀前端创新

React 不再因技术优势而获胜。今天，它已经是默认的选择。这种默认选择现在正在减缓前端生态系统的创新。

当团队需要一个新的前端时，对话通常很少从“有哪些限制，哪个工具最适合它们？”开始。而是从“我们使用 React；每个人都了解 React。”开始。这种条件反射创造了一个自我持续的循环，在这个循环中，决定架构的是网络效应，而不是技术契合度。

与此同时，真正创新的框架难以获得采用。Svelte 编译掉了框架开销。Solid 提供了细粒度的反应性，无需虚拟 DOM 税。Qwik 通过可恢复性实现了即时启动。这些方法可以在常见场景中优于 React 的模型，但由于 React 是默认选择，它们很少得到公平的评估。

React 在许多方面都做得很好。问题不在于 React 本身，而在于默认选择 React 的心态。

创新天花板

React 的技术基础解释了当今的一些摩擦。虚拟 DOM 是 2013 年问题的聪明解决方案，但正如 Rich Harris 在“虚拟DOM是纯粹的开销”中概述的那样，它引入了现代编译器通常可以避免的工作。

钩子解决了类组件的痛点，但引入了新类型的复杂性：依赖数组、陈旧的闭包和误用的 Effect。即使是 React 自己的文档也强调克制：“你可能不需要一个Effect”。服务器组件提高了首字节时间，但增加了架构复杂性和新的故障模式。

React编译器是一个智能的解决方案，可以自动执行诸如 useMemo / useCallback 之类的模式。它的存在也是一个信号：我们正在围绕模型中固有的限制进行优化。

将此与其他方法进行对比：Svelte 5 的Runes在编译时简化了反应性；Solid 的细粒度反应性精确更新了变化的内容；Qwik 的可恢复性消除了传统的水合。这些不是对 React 模型的增量调整——它们是具有不同天花板的不同模型。

没有采用的创新不会改变结果。当选择是出于条件反射时，采用就无法发生。

我们都背负着技术债

默认选择 React 通常会带来我们不再质疑的运行时和调和成本。即使它足够快，上限也低于编译时或细粒度模型。开发者的时间花在管理重新渲染、effect 依赖项和水合边界上，而不是交付价值。从性能研究中得到的更广泛的教训是一致的：JavaScript 在关键路径上是昂贵的（JavaScript的成本）。

我们把思维模型集中在“React 模式”上，而不是 web 基础上，这降低了技能的可移植性，更有可能导致架构惰性。

损失的不仅仅是性能，还有机会成本，因为更合适的替代方案从未得到评估。例如，像 JS框架基准测试这样的基准测试显示，与 React 相比，Solid 等替代方案在反应性重的场景中实现了高达 2-3 倍的更快更新速度。

被压抑着的框架

Svelte：编译器革命

Svelte 将工作转移到编译时：没有虚拟 DOM，最小的运行时。组件成为目标 DOM 操作。心智模型与网络基本原理对齐。

但是“没有足够的工作”人为地降低了 Svelte 的采用率，管它在大多数用例中具有技术优势。像卫报采用 Svelte 作为他们的前端这样的现实世界例子，展示了性能和开发者生产力的可衡量收益，据报道，包大小减少了，加载时间也加快了。例如，正如 Wired 关于Svelte的文章中所详细说明的，开发者 Shawn Wang（X/Twitter 上的@swyx）通过利用其编译时优化，将他的网站大小从 React 的 187KB 减少到仅 9KB 的 Svelte，这将框架开销从运行时上转移开。这导致更快、更高效的应用程序，特别是在慢速连接上。

Solid：反应性原语方法

Solid 提供了熟悉 JSX 的细粒度反应性。更新通过信号直接流向受影响的 DOM 节点，绕过调和瓶颈。强大的性能特征，有限的心智份额。正如 Solid 的比较指南中概述的，这种方法比 React 的虚拟 DOM 实现了更有效的更新，精确的反应性最小化了不必要的工作，并通过更简单的状态管理提高了开发者体验。

虽然与更成熟的框架相比，突出的案例研究较少，但这主要是由于 Solid 的采用率较低。然而，来自早期采用者的轶事报告表明，在更新效率和代码简单性方面也有类似的变革性收益，随着更多团队的实验，这些收益将被扩展和共享。

Qwik：可恢复性创新

Qwik 使用可恢复性代替水合，通过仅加载当前交互所需的内容实现即时启动。这对于大型网站、长时间会话或慢速网络非常理想。根据 Qwik 的“Think Qwik”指南，这是通过渐进式加载和序列化状态和代码来实现的。因此，应用程序可以立即恢复执行，而无需繁重的客户端引导，与传统框架相比，这带来了更好的可扩展性和更短的初始加载时间。

Qwik 的成功案例可能不那么明显，仅仅是因为较少的团队打破默认设置尝试它。但那些尝试过的人报告了启动时间和资源效率的显著改进，这表明如果采用率增长，将有大量未开发的潜力。

所有三种方法被低估的原因不是因为它们缺乏优点，而是因为默认选择阻碍了尝试。

此外，React 的 API 表面积明显比其替代品更大、更复杂，涵盖了钩子、上下文、约简器和记忆模式等概念，需要仔细管理以避免陷阱。这种广泛的 API 为开发者带来了更高的认知负荷，常常导致由于误解依赖关系或过度工程化而产生的缺陷。例如，在Cloudflare 2025年9月12日的停机事件中，一个 useEffect 钩子和一个有问题的依赖数组触发了重复的 API 调用，压垮了他们的租户服务，导致了广泛的故障。相比之下，像 Svelte、Solid 和 Qwik 这样的框架具有更小、更专注的 API，强调简单性和网络基础，减少了心理负担，使它们更容易掌握和维护。

网络效应的监狱

React 的主导地位创造了自我强化的障碍。招聘广告要求“React 开发人员”，而不是“前端工程师”，这限制了技能的多样性。组件库和团队肌肉记忆创造了制度惯性。

风险厌恶的领导者选择“安全”的选项。学校教授工作要求的内容。这个循环不受技术价值的影响而继续。

这不是良性竞争；这是默认的生态系统捕获。

打破网络效应

逃离需要在多个层面上采取深思熟虑的行动。技术领导者应该根据约束和优点来进行选择，而不是基于势头。公司可以分配一个小的创新预算来尝试替代品。开发人员可以超越单一的思维模式进行技能提升。

教育者可以在教授特定工具的同时教授与框架无关的概念。开源贡献者可以帮助替代生态系统成熟。

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

框架评估清单

在开始一个新项目时，使用这个简单的清单来做出有意识的选择：

• 评估性能需求：评估启动时间、更新效率和捆绑包大小等指标。如果速度至关重要，那么优先选择具有编译时优化的框架。

• 团队技能和学习曲线：考虑现有的专业知识，但要考虑到迁移路径；许多替代品提供温和的坡道（例如，Solid 与 React 的 JSX 兼容性）。

• 扩展和拥有成本：计算长期成本，包括维护、依赖管理和技术债。替代品通常可以减少运行时开销，降低托管成本并提高可扩展性。

• 生态系统适应性：在成熟度和创新之间取得平衡；在非关键领域进行试点，以测试迁移的可行性和投资回报率。

标准反驳论点

“但是生态系统成熟度！”成熟度是有价值的，也可能使惯性根深蒂固。年龄不等于适应当今的约束。

此外，成熟的生态系统通常意味着严重依赖第三方包，这可能会引入维护负担，如保持依赖关系最新、处理安全漏洞、以及使用未使用到的代码使包膨胀。虽然在某些情况下是必要的，但这种灵活性可能导致过度依赖；从长远来看，针对特定需求量身定制的解决方案通常更精简、更易于维护。替代框架中的较小生态系统鼓励从基础构建，培养更深入的理解和较少的技术债。此外，随着 AI 编码助手现在能够按需生成精确的定制功能，创建定制实用程序的障碍已经大大降低了。这使得避开像 lodash 这样的通用库或像 Moment 或 date-fns 这样的日期库来完全支持轻量级的、特定于应用程序的实现成为可能。

“但是招聘！”招聘跟随需求。你可以通过在非关键路径上试点替代品，然后在招聘基础加上在职培训来降低风险。

“但是组件库！”框架无关的设计系统和 Web 组件减少了锁定，同时能保持速度。

“但是稳定性！”React 从类到钩子再到服务器组件的演变表明了不断的混乱，而不是稳定性。替代框架通常能提供更一致的 API。

“但是经过规模证明！”jQuery 也经过了规模证明。过去的成功并不能保证未来的相关性。

更广泛生态系统的危害

当一个框架的约束成为事实上的限制时，单一文化会减缓 Web 的演变。人才花时间解决特定框架的问题，而不是推动平台向前发展。不管技术优势如何，投资总是追随在位者。

课程优化了直接就业能力，而不是基础知识，创造了特定框架而非可转移的技能。平台改进会被推迟，因为“React 可以处理”成为了默认答案。

当多样性消失时，整个生态系统都会受到影响。

我们本可以成长的花园

健康的生态系统需要多样性，而不是单一文化。当不同的方法竞争和交叉授粉时，创新就会出现。开发者通过学习多种思维模式而成长。当几个框架突破不同的界限时，平台就会得到了改善。

把所有赌注都押在一个模型上会造成单点故障。如果它遇到硬性限制会怎样？我们不探索替代方案会错过什么机会？

是时候根据限制和价值而非势头来选择框架了。你的下一个项目值得比默认的 React 更好。生态系统值得多样性才能提供的创新。

不要再默认种植相同的种子。通过多样化框架探索，我们本可以培育的花园将比我们逐渐陷入的单一文化更具韧性和创新性。

选择权在我们手中。

原文链接：

https://www.lorenstew.art/blog/react-won-by-default