为何现代 JavaScript 框架正朝着同一方向迈进

摘要:还记得当初选框架就像加入某场“圣战”吗?React 派嘲讽 Angular “臃肿”,Vue 支持者自诩折中之选,JSX 是天才发明还是罪恶源头吵得难解难分。如今,剧情反转:这些框架竟然风格越来越相似。

还记得当初选框架就像加入某场“圣战”吗?React 派嘲讽 Angular “臃肿”,Vue 支持者自诩折中之选,JSX 是天才发明还是罪恶源头吵得难解难分。

如今,剧情反转:这些框架竟然风格越来越相似。

过去几年,我亲眼见证了它们的不断趋同。曾经各执一词的多种开发思路,如今相互借鉴之深,让人时常分不清自己到底在用哪个框架。


1. 状态管理的大迁徙:信号(Signals)

最大的“出轨证据”莫过于信号。

三年前若有人说 Angular 会拥抱 SolidJS 那套响应模型,我定会笑出声。但到了 2025 年,信号已经在多款主流框架里占据一席之地:

  • **Angular 16+**:内置细粒度信号响应
  • Svelte 5:底层用信号实现响应,但对开发者透明
  • SolidJS:信号之始祖
  • Preact:信号为首选状态管理
  • Qwik:从诞生之初即拥抱信号
  • Lit 3:Google 的 Web Component 框架,正式引入信号

就连 Vue 虽未明称“信号”,其底层原理亦与之异曲同工。React 目前仍是“例外”,但压力山大不言而喻。

为何信号称王?

它直击无谓重渲染的痛点。传统 React 模式是:状态改动就重跑整个组件树;信号则精确追踪数据依赖,只更新真正需要刷新的那一小部分。

// 旧模式(React)
function App({
  const [count, setCount] = useState(0);
  return (
    <div>
      <p>{count}</p>
      <HeavyThing /> {/* 也会被一起重渲染 */}
      <button onClick={() => setCount(c => c + 1)}>+</button>
    </div>
  );
}

// 新模式(信号)
function App({
  const [count, setCount] = createSignal(0);
  return (
    <div>
      <p>{count()}</p>       {/* 仅此处更新 */}
      <HeavyThing />        {/* 保持不变 */}
      <button onClick={() => setCount(c => c + 1)}>+</button>
    </div>
  );
}

结果是更少的计算、更快的交互响应(如 INP 指标提升)。


2. 组件化架构的共识

曾几何时,Angular 有“指令”,React 有“组件”,各自标榜与众不同。随着 React 推崇组件化,Angular 社区也在 1.x 里实验“组件式指令”,到 1.6 引入 angular.component(),再到 2.0 才真正切换组件模型。Vue 自始至终以组件为核心。

现今,所有框架都在玩组件。语法虽异,思想一致:

// React
function Welcome({ name }{
  return <h1>你好,{name}</h1>;
}

// Vue
<template><h1>你好,{{ name }}</h1></template>
<script>export default { props: ['name'] }</script>

// Angular
@Component({ selector'welcome'template'<h1>你好,{{ name }}</h1>' })
export class Welcome { @Input() name: string; }

封装逻辑、可复用单元、Props 下行、事件冒泡——模式一脉相承。


3. 服务器端的复兴

更耐人寻味的是,大家都在向同一个「服务器优先」目标冲刺:在服务器渲染,客户端按需「激活」。

  • Next.js:Server Components + 部分水合
  • Angular:非破坏式水合,正在测试局部水合
  • Nuxt:通用渲染 + 灵活水合
  • SvelteKit:SSR + 客户端增强
  • Astro:默认零 JS,岛屿架构
  • Remix:Server-First + 渐进增强

共同点:减少发往浏览器的 JS,关键交互处再加载,以求最优性能。


4. 文件路由无处不在

还记得路由配置要手动写一堆文件、折腾无尽 plugin 吗?当年 Next.js 首创的基于文件的路由目录风潮,如今被:

  • SvelteKit
  • Nuxt
  • Astro
  • Remix
  • 实验性 Angular

一并照搬:pages/index.js 对应 /pages/blog/[slug].js 对应 /blog/:slug,语法一致,约定胜过配置。


5. 性能优化套路

框架们在性能优化上也殊途同归,常见手段包括:

  1. 代码切割:拆分包,只加载需要的模块
  2. 懒加载:异步加载组件或路由
  3. 摇树优化:剔除无用代码
  4. 图片优化:自动响应式及延迟加载
  5. 包体分析:内置可视化工具

最佳实践几乎可以在不同框架间“一键迁移”。


6. 开发体验(DX)竞赛

为留住开发者,框架们在工具链和体验上也不断靠拢:

  • 热模块替换(HMR):都支持
  • TypeScript:一等公民
  • 调试扩展:Chrome 插件齐备
  • CLI 脚手架:模板、构建一致
  • 插件系统:扩展机制类似

连报错提示,都在相互学习改进。


7. 编译器之争:React Compiler 与 Svelte 5 Runes

2024 年最有趣的发展,当属 React Compiler 的登场:自动优化、减少重执行,思路与 2019 年 Svelte 3 编译器如出一辙。与此同时,Svelte5 又悄然拥抱信号(曾声称不需信号),让人啧啧称奇。


对开发者意味着什么?

  • 技能通用:概念学一次,多端适用。
  • 降低锁定:按相同模式重构升级更容易。
  • 工具互通:可跨框架使用的分析和插件更多。
  • 实践更加统一:最佳方案已被验证。

仍在坚守与持续创新

React 是信号阵营里最大的“例外”,但也通过编译器试图挽回性能;新晋框架如 Qwik 则主打「可恢复性」,让服务端执行状态能无缝在客户端续航。


小结

现代前端生态正朝着组件化、信号响应、服务器渲染与按需水合、文件路由,以及卓越开发体验等稳定模式收敛。框架之争未尽,但基础套路已日渐一致。与其纠结模板与 JSX 的孰优,不如携手用同样高效的方式,创造更卓越的用户体验。

来源:https://mp.weixin.qq.com/s/1vjeSx4DFIMxul0kSuxDOw

本文内容仅供个人学习、研究或参考使用,不构成任何形式的决策建议、专业指导或法律依据。未经授权,禁止任何单位或个人以商业售卖、虚假宣传、侵权传播等非学习研究目的使用本文内容。如需分享或转载,请保留原文来源信息,不得篡改、删减内容或侵犯相关权益。感谢您的理解与支持!

链接: https://shenqiku.cn/article/FLY_12854