导读：原生浏览器 API 现在已为路由、状态管理和组件提供了强大的替代方案。别再纠结框架了，直接用浏览器就能做得很好。

以前的网络给人感觉像一个杂乱的集市，充斥着各种相互竞争的理念、半残破的库，以及一些用胶布粘起来的解决方案，假装是个标准。后来，框架（Framework）就如同救世主一样昂首阔步，承诺给互联网带来秩序。

但是，现在发生了一些奇奇怪怪的事情：浏览器本身正在将许多框架的超能力直接吸收到平台中。

框架并没有立即消亡，但它们对开发者体验的垄断正在瓦解，标准化运动也比十年前更加激烈。

可以说，现在的技术竞争不再是 React 、Vue和 Angular 之间的较量，因为三者已经联手，对抗一个新的对手，那便是浏览器。

框架始终只是个补丁，而不是解决方案

框架之所以占据主导地位，是因为 Web 平台坦白地说还没有为现代应用程序开发做好准备。开发者需要路由、状态管理、模板、组件隔离——而浏览器却无法提供所有这些功能。

React 和Angular 并不是仅仅因为炒作而流行；它们填补了标准长期忽视的巨大空白。但要说句实话：它们始终只是权宜之计。它们的 API 让 Web 变得可行，但往往以牺牲很多性能和复杂性为代价。

想想React 的虚拟 DOM：一个巧妙的 hack，让 DOM 操作变得轻松许多。或者 Angular 的双向绑定，它看起来很神奇，直到你看到它在规模化时造成的混乱。这些想法之所以蓬勃发展，是因为平台当时落后了。

框架的不宣秘密是，它们在沙子上建造城堡，而浏览器最终在它们下面铺平了坚实的地面。

时光到了 2025 年，当平台本身提供诸如模板字面量、Shadow DOM 或新的 Web Components API 之类的解决方案时，我们真的需要这些间接层吗？框架的不宣秘密在于，它们在沙地上建造城堡，而浏览器最终会在它们下面铺平坚实的地面。这种转变有可能改善发布管理、代码维护等等。

原生平台功能的兴起

新的原生标准正在蚕食曾经专属于框架的功能，而且这种变化的速度比很多人意识到的还要快。比如：

Shadow DOM 现在提供了真正的组件封装，无需第三方库。ES 模块消除了脚本标签的依赖关系，为我们提供了原生的导入和导出功能。再加上 fetch、async/await 和 streams——这些功能曾经需要 polyfill 或成熟的库才能实现——这个平台看起来与十年前判若两人。

就拿路由来说，它长期以来一直是框架皇冠上的明珠。导航 API 和视图转换 API 允许开发者用最少的代码创建流畅、类似原生的导航效果。状态管理？

信息很明确：框架不再是现代网络构建模块的守门人。

信号和响应式原语正在直接进入标准讨论，框架所推广的相同理念正在被重写到浏览器的 DNA 中。当你将所有这些与 Web 动画 API、CSS 容器查询以及稳步推进的性能 API 结合起来时，Web 平台开始不再像一个半成品，而更像是一个先进且实用的操作系统。

我说的并非纸上谈兵。主流应用程序已经在依赖这些原生功能，从而减少包大小和维护负担。信息很明确：框架不再是现代 Web 构建模块的守门人。

框架仍然不会消失

宣称框架已经完结，未免有些懒惰。它们仍然在解决一些难题，尤其是在开发人员工效学、大型团队扩展以及自成体系的架构等方面。

框架提供了约定，这些约定可以节省代码审查中数小时的争吵。标准虽然取得了长足的进步，但其设计理念是灵活且精简的——它们很少规定如何实际组织代码。

想想 React 的生态系统：库、工具、围绕状态的约定以及庞大的开发者群体。即使浏览器提供了与 Hooks 或 Context 等价的功能，React 的强大用户粘性依然不可撼动。Angular 仍然在企业中蓬勃发展，因为它是一个功能齐全的解决方案。而像 Svelte 或 SolidJS 这样的新框架则不断在人机工程学方面进行创新，而不是仅仅追求与标准保持一致的原始功能。

真正的转变不是框架的消失，而是框架被迫证明自己的合理性。

真正的转变不是框架的消失，而是框架被迫证明自己的合理性。十几年前，你需要一个框架来构建一个严肃的应用程序。而今天，如果你想要严格的约定、生态系统锁定，或者你的团队重视某些人体工程学，你就需要一个框架。这是一个根本的区别：框架正在从必需品变成偏好。

性能争论：原生 vs 框架

多年来，框架一直以网络太过混乱为借口，因此牺牲一些性能是值得的。开发人员忍受着臃肿的包、令人头痛的“水合”问题以及运行时 hack，因为开发人员的体验似乎值得。

但是现在，这种说法已然站不住脚了。

原生解决方案通常比框架方案表现更优异。简单总结来说如下：

• 自定义元素的渲染速度比许多虚拟 DOM 抽象更快。
• CSS 容器查询消除了曾经使用脆弱的 JavaScript 处理的整个布局黑客类别。
• 导航 API 取代了繁重的客户端路由器，后者需要数千字节的代码才能模仿本机导航。

更为“残酷”的是它对性能敏感环境的影响。移动优先的应用、新兴市场的连接以及边缘计算都需要效率。与精简、基于标准、加载迅速、运行流畅的应用相比，一个充斥着依赖关系的 React SPA则显得愚笨至极。

浏览器供应商实际上是在鼓励开发者停止使用数十兆字节或更臃肿的 JavaScript，并使用已经内置的工具。在这种情况下，框架看起来更像是一种性能负担，而不再是一种生产力工具。

抢占开发者心智的“政治斗争”

这场“斗争”并非纯粹的技术之争，而是“政治”之争。框架拥有庞大的营销机器，背后有数个既得利益集团的支持。

比如Meta 支持 React，因为它支撑着他们的系统帝国；而Google支持 Angular，因为它能让开发者与其生态系统紧密相连。

相比之下，标准则是由行动迟缓的委员会与工作组制定的，它们缺乏框架赖以生存的品牌效应和炒作周期。

然而，有些事情正在发生着变化：浏览器供应商越来越意识到，框架不能一直决定网络的方向。

标准的设计目的是直接与框架功能竞争，而不是落后于它们。

标准的设计初衷是直接与框架功能竞争，而不再是落后于它们。像开放 Web 组件 (Open Web Components) 这样社区的兴起，表明人们渴望再不受企业把关的合作。

然而，技术文化惯性依然存在。大学教授 React，训练营推广 Angular，招聘信息也用框架专用的某种语言编写。而且，标准也存在诸多公关问题。

浏览器以及提供商们正在向开发者展示现代级平台足够强大、无需额外增加臃肿功能的布道者。在此之前，即使框架的技术护城河正在缩小，它们仍将凭借纯粹的市场占有率保持竞争力。

结语

诚然，框架们曾经拯救了网络，使其免于自身诸多能力的不足。如今，它们开始看起来像浏览器主办之聚会上的中间人。如果你还在用浏览器无法处理的方式编写代码，那么你已经忽略了二十年来前端开发最重要的技术转变。

是的，框架不会在明天立即消失，但它们的主导地位正在逐渐减弱。标准化运动正处于几十年来最激烈的时期，浏览器正在一点一点地蚕食框架的蛋糕。

盲目依赖框架的开发者可能会开发出臃肿过时的应用程序，而与此同时，其他网络平台却在飞速发展。

这传达的信息很简单：是时候再次认真对待浏览器了。

作者：洛逸