然而，十余年过去，前端环境和硬件性能已经发生了巨大变化。虚拟 DOM 不再是唯一高效的答案，生态中的许多替代方案——如 Svelte、Solid、Qwik——在性能和开发体验上展现出明显优势。与此同时，React 虽然依旧是默认选择，却逐渐显露出“默认惯性”的一面：招聘市场围绕 React 定义岗位，教育体系优先教授 React，团队习惯性在新项目中选择 React。这种路径依赖让创新框架很难突破，也让前端生态的多样性受到限制。
对于他的评价，有人认可有人反对，这一争论甚至冲上了 HN 热榜，而他究竟说了什么？我们在本文中一探究竟。
作者 | Loren Stewart 责编 | 苏宓
默认使用 React 是有隐性成本的。下面是一个主张：在选用框架时，应当有意识地做出选择，挑选最适合的工具。
当团队需要一个新的前端框架时，讨论很少从“我们的约束条件是什么，哪个工具最合适？”开始。更多时候，话题直接落在“用 React 吧，大家都懂 React。”这种下意识的选择制造了一个自我循环，架构的决定往往不是基于技术契合度，而是基于网络效应。
React 在很多方面都很优秀。问题不在 React 本身，而在于「默认用 React」的思维方式。
React 的技术基础，解释了当下部分摩擦的根源。虚拟 DOM 在 2013 年是一个聪明的解决方案，但正如 Svelte 的主力开发者 Rich Harris 在《Virtual DOM is pure overhead》中指出的，它引入了许多现代编译器本可以避免的开销。
React Compiler 是一款智能的工具，可以自动化 useMemo/useCallback 之类的模式。但它的存在本身也是一种信号：我们仍在为模型里固有的约束做补丁和优化。
有创新但没人用，也解决不了问题。如果大家只是习惯性地选一个框架，那新的东西根本没机会被采用。
默认使用 React，往往意味着我们无条件接受它的运行时和协调成本。即便在很多情况下“够快”，它的上限依然低于编译期或细粒度模型。开发者花费大量时间在管理重新渲染、Effect 依赖、hydration 边界上，而不是在交付业务价值。性能研究给出的总体结论是一致的：Javascript 在关键路径上代价高昂。
损失的不仅仅是性能，还有当更合适的替代方案从未被评估时的机会成本。比如，在 JS framework Benchmark这样的基准测试中，Solid 在响应式密集的场景下，更新速度往往比 React 快 2–3 倍。
Svelte：编译器革命
然而，“缺乏足够的岗位需求”让 Svelte 的采用率被人为压低，即使在大多数用例里它有更突出的技术优势。真实案例已经证明它的价值：例如 The Guardian在前端中引入 Svelte 后，性能和开发效率都有显著提升，打包体积减少，加载速度加快。再比如外媒Wired的报道提到，开发者 Shawn Wang（X/Twitter 上的 @swyx）将自己的网站从 React 的 187KB 缩减到仅 9KB，正是依靠 Svelte 的编译期优化，把框架开销从运行时剥离。这种机制让应用在慢速网络下也能更快、更高效。
Solid 提供细粒度的响应式，并保留了 JSX 的熟悉体验。更新通过 signal 直接流向受影响的 DOM 节点，完全绕过协调（reconciliation）的瓶颈。它具备强劲的性能特征，但知名度有限。
虽然与更成熟的框架相比，Solid 的典型案例还不算多，但这主要源于采用率偏低。来自早期用户的反馈显示，它能带来更新效率和代码简洁性的显著提升，只待更多团队尝试和扩展，才能得到更广泛的验证。
Qwik 采用可恢复性（resumability）而不是 hydration，让应用只加载当前交互所需的内容，从而实现即时启动。这对大型站点、长时间会话或慢速网络尤为理想。根据 Qwik 的 Think Qwik指南，它通过渐进式加载以及状态与代码的序列化来实现应用恢复，无需繁重的客户端初始化。结果是具备更好的可扩展性和更短的初始加载时间。
这三个框架之所以“被低估”，并不是因为技术不够优秀，而是因为“默认选择”阻碍了它们的试用。
网络效应的囚笼
风险规避型的管理者会选择“最安全”的选项。学校教授市场所需的技能。于是，这个循环在技术优劣之外继续运转。
打破网络效应
教育者可以在教授具体工具的同时，加入与框架无关的概念。开源贡献者则能帮助替代生态逐步成熟。
框架评估清单
评估性能需求：考量启动时间、更新效率、打包体积等指标。如果速度至关重要，应优先考虑具备编译期优化的框架。
扩展性与长期成本：计算长期开销，包括维护、依赖管理和技术债。替代框架通常减少运行时开销，降低托管成本，并改善可扩展性。
常见的反驳理由
其实成熟的生态固然有价值，但也可能加深开发者的惰性。年头长不等于适合今天的约束。成熟生态往往意味着对第三方包的高度依赖，这会带来额外维护成本：需要不断更新依赖、应对安全漏洞，甚至因未使用的代码而导致打包膨胀。
招聘随需求而动。可以先在非关键路径试点替代框架，以此降低风险，再通过招聘基础扎实的开发者并提供上手培训来填补技能差距。
React 从类组件到 Hooks，再到 Server Components，本身就是不断变动，而非稳定。许多替代框架反而提供更一致的 API。
更广泛的生态损害
课程更关注“立即就业”而非基础知识，培养出的是框架专属技能，而非可迁移的能力。平台改进也因此被延后，因为“React 可以搞定”成了默认答案。
我们可以做的事情
把所有赌注压在一种模型上，就等于制造了单点风险。一旦它遇到硬性瓶颈会怎样？我们又错过了多少本该探索的机会？
不要再默认种下同一颗种子。通过多样化框架探索，我们本可以培育出一个更具韧性、更具创新力的花园，而不是滑向单一化的荒地。选择权，就在我们手中。
