前端发展概述：从静态文档到群岛架构

• 1. 原始时代（约 1990—2004）：文档网络
• 2. MVC 时代（约 2005—2012）：动态网页的秩序
• 3. MVVM 与 SPA 时代（约 2013—2018）：客户端接管一切
• 4. 大前端时代（约 2017—至今）：跨越平台边界
• 5. 渲染架构的分化：SSR、SSG、ISR 与 RSC
  • 5.1 渲染策略光谱
  • 5.2 渲染策略选择框架
• 6. Edge 渲染架构：把计算推到离用户最近的地方
• 7. 群岛架构：把"该交互的"和"该静态的"分开运输
• 8. 五条支线的演进地图
  • 8.1 硬件性能
  • 8.2 JavaScript 引擎
  • 8.3 语言演进
  • 8.4 构建工具链
  • 8.5 框架灵活性的螺旋上升
• 9. 2026 年的技术栈推荐
• 10. 总结
• 参考文献

1990 年，Tim Berners-Lee 在 NeXT 工作站上敲出第一个浏览器时，前端不过是一堆带 <a> 标签的纯文本。三十五年后，你在浏览器里打开一个 Notion 文档，它加载了数百个 JavaScript 模块，运行着一个微型的 React 运行时，通过 WebSocket 同步协作状态，也许还有一个小型 SQLite 引擎在 IndexedDB 里运转。前端的发展不是一条直线。它更像一棵不断分叉的树，每个分叉都在回应当时硬件、网络、用户习惯的约束^[1][2]。

本文聚焦架构范式的跃迁——每次跃迁的驱动力是什么，解决了什么核心矛盾，又带来了什么新问题。主线是人机交互能力的持续升级，支线是硬件演进、语言演进、工具链变革三条并行轨道。

1. 原始时代（约 1990—2004）：文档网络

核心矛盾：如何在分散的计算机之间共享格式化文档。

HTML 的源头比 Web 本身更古老。1960 年代，IBM 开发了通用标记语言（GML），用于在政府、法律和工业领域共享需要数十年内保持可读的大型文档。GML 后来标准化为 SGML（Standard Generalized Markup Language），但由于规范过于复杂，始终没有普及。HTML 是 SGML 的一种简化实现，1998 年 XML 作为 SGML 的另一个精简子集出现，才正式替代了 SGML 在数据交换中的地位^[3]。

1990 年，物理学家 Tim Berners-Lee 在 CERN 创立了 HTML（HyperText Markup Language），用一些特殊标签来定义文本格式。他面临的问题很具体：科学家之间分享论文太慢。1991 年他发布了 WorldWideWeb 浏览器（后改名 Nexus），这款图形化浏览器包含一个所见即所得的 HTML 编辑器。同年他招募 Nicola Pellow 开发了行模式浏览器，用于在命令行终端上浏览 HTML 内容^[4]。后来成为 HTML 2.0 规范主编的 Dan Connolly 也在 1994 年加入 W3C，参与推动了 Web 标准化工作。

1991 年，HTTP/0.9 协议通过。这份不到 700 个英文单词的文献定义了 HTTP 最基本的功能：传输 HTML 文档。它只有一个方法 GET，不支持传输其他文件，也不支持上传——只能由客户端向服务器请求 HTML 内容^[5]。

1993 年 6 月 IETF 发表了第一份 HTML 规范提案但未标准化，Dave Raggett 同年提出的 HTML+ 草案同样未标准化——两者被笼统称为 HTML 1.0。同一年 Mosaic 浏览器发布，其图形化界面将 Web 带向大众。Chrome、Firefox 等现代浏览器至今仍在沿用 Mosaic 的图形化操作界面思想。

1994 年 W3C 成立，Mosaic 团队领导人 Marc Andreessen 创立网景公司并推出 Netscape Navigator。1995 年 Yahoo 创办，在那个 PC 和网络远未普及的年代，让越来越多人认识到技术革命的新浪潮。

1995 年，网景公司决定在浏览器中嵌入脚本语言。他们走了两条路：与 Sun 合作嵌入 Java（因复杂和不安全问题未普及），以及聘请 Brendan Eich 嵌入 Scheme 语言。Eich 花了 10 天设计出一种解释语言，最初在 1995 年 9 月以 LiveScript 之名发布，同年 12 月正式发布时改名为 JavaScript。命名上的"Java"关联是营销策略，两种语言在技术上几乎没有关系^[6]。

同年微软推出 IE 浏览器与网景竞争，并通过逆向工程写出 JavaScript 的克隆版 JScript（1996 年发布）。微软刻意保持 JScript 与 JavaScript 的差异，导致开发者不得不在页面标注 "best viewed in Netscape" 或 "best viewed in Internet Explorer" 的标志。1996 年 11 月网景将 JavaScript 提交给 ECMA，1997 年 6 月 ECMAScript 1 正式发布。ES2 在 1998 年 6 月发布，ES3 在 1999 年 12 月发布。ES4 的工作在 2000 年启动但最终搁置——改动太大，浏览器厂商无法接受。

到 21 世纪初，IE 市场份额达 95%，JScript 成为客户端脚本的事实标准，微软退出了 ECMA 标准工作，ES4 就此夭折。直到 2015 年 6 月，ECMAScript 6（ES2015）才发布，此后每年发布一个新版本。

这个时代的"架构"几乎不存在。一个 PHP 文件里混着 SQL 查询、HTML 模板、CSS 内联样式，表单提交一次就要重载整页。把这件事放在 2026 年看，相当于每次点击菜单都要把整个餐厅重新装修一遍。

主线推进：人类第一次可以跨越地理距离共享富文本。支线状态：1997 年主流 CPU 是 Pentium II 233MHz，内存 32MB，56K 调制解调器下载一张 100KB 图片需要 15 秒。

2. MVC 时代（约 2005—2012）：动态网页的秩序

核心矛盾：网页从文档变成了应用，但代码组织方式还是文档的。

2004 年 Gmail 发布。2005 年 Google Maps 上线。Jesse James Garrett 在那年写了一篇文章，给一个已经存在几年的技术组合起了名字：Ajax^[7]。这件事的实质是 XMLHttpRequest 让浏览器可以在不刷新页面的情况下向服务器要数据。用户体验的质变来自一个简单的步骤：每次点击不再需要重载整个页面。

服务端 MVC 框架在这个时期成熟。Struts（Java）、Ruby on Rails（2004）、Django（2005）、CakePHP（2005）、ASP.NET MVC（2007）、Spring MVC（2009）依次出现。Model 管理数据，View 负责模板，Controller 协调两者。当用户需要注册时，View 与用户交互指导输入信息，Controller 处理输入后在 Model 中新增记录并交给数据库持久化。这种分层让团队可以分工：有人写 SQL，有人写 HTML，有人写业务逻辑。

客户端这边，jQuery 在 2006 年发布。它解决了一个极其痛苦的问题：不同浏览器对 DOM 操作的实现各不相同。$('#id').hide() 在 IE6、Firefox 2、Safari 3 上都能工作——这对当时的开发者来说是革命性的。jQuery 的峰值使用率超过了 70% 的全球网站^[8]。

但 MVC 时代的核心问题也在 jQuery 的流行中暴露出来：DOM 操作散落在各处，状态管理靠 DOM 本身——你要判断一个按钮是否已点击，得检查它的 CSS class 或者 data 属性。页面逻辑变成意大利面条，维护成本随功能数量线性增长。

主线推进：网页第一次有了应用级的交互体验。支线推进：2006 年 AWS 上线，2008 年 Google 发布 V8 引擎和 Chrome 浏览器，JIT 编译让 JavaScript 执行速度提升了 10 倍以上^[9]。Node.js 在 2009 年出现，前端工程师第一次可以用同一种语言写服务端代码。GitHub 在 2008 年上线，npm 在 2010 年发布，开源协作的门槛大幅降低。

3. MVVM 与 SPA 时代（约 2013—2018）：客户端接管一切

核心矛盾：DOM 操作和状态同步太容易出错。界面复杂到一定程度后，人脑无法跟踪所有更新路径。

2010 年，Google 的 Miško Hevery 发布了 AngularJS。它的核心思想是数据绑定——你在 JavaScript 对象上改一个值，DOM 自动更新。Backbone.js 也在同年出现，提供了更轻量的 Model-View 分离方案。2013 年 Facebook 发布 React，核心是虚拟 DOM——你在内存里构建一棵组件树，框架算出最小变更集合，然后批量更新真实 DOM。2014 年 Evan You 发布 Vue.js，把 AngularJS 的模板语法和 React 的响应式系统揉在一起，学习曲线更平滑。

这三个框架代表了 MVVM 模式在前端的不同实现路径：

• AngularJS：脏检查。每次 digest 循环遍历所有 watcher，检查值是否变化。简单直观，但在大量绑定时性能下降明显。
• React：虚拟 DOM diff，不可变状态。显式调用 setState() 触发重新渲染，单向数据流让数据变化可追溯。
• Vue：基于 Object.defineProperty（后改为 Proxy）的响应式系统。自动追踪依赖，精确知道哪个组件需要重新渲染。

MVVM 模式解决了 MVC 时代的核心痛点：DOM 不再是状态的来源，JavaScript 对象才是。视图变成状态的函数——$V = f(S)$。这个公式听起来简单，但它改变了前端开发的整个思维模型。

SPA（Single Page Application）架构在这个时期成为主流。用户在 /login 和 /dashboard 之间导航时，浏览器实际上没有向服务器请求新的 HTML 文档——JavaScript 路由器拦截 URL 变化，替换页面内容。体验上像原生应用，但代价有三：首屏加载慢（要下载整个 JS bundle），SEO 困难（爬虫看到的是空 <div id="root">），浏览器内存占用高。

2015 年 ECMAScript 6（ES2015）发布，带来了 class、const/let、箭头函数、Promise、模块系统。TypeScript 在同年被 Angular 团队宣布为 Angular 2 的开发语言（Angular 2 最终于 2016 年 9 月正式发布），从此静态类型检查在前端工程化中占据一席之地。Webpack 在 2014 年发布，终结了 Grunt/Gulp 时代的配置混乱，但带来了新的配置地狱。

主线推进：Web 应用的用户体验跟原生应用的差距缩小到几乎不可感知。支线推进：V8 引擎持续优化（TurboFan 编译器在 2015 年发布），移动端 CPU 性能每年增长 20-30%，React Native 在 2015 年发布，前端开始触及移动端。

4. 大前端时代（约 2017—至今）：跨越平台边界

核心矛盾：同一套业务逻辑，要在 Web、iOS、Android、小程序、桌面五个平台上各写一遍。

"大前端"不是一个技术术语，而是对一类趋势的描述：前端技术栈的势力范围从浏览器扩展到了所有需要图形界面的终端。这个趋势由三个推力驱动：

1. React Native / Flutter / uni-app 让 JavaScript 开发者可以产出移动端 App。React Native 在 2015 年提出"learn once, write anywhere"，2018 年重构了底层通信桥，自 2022 年随 RN 0.68 引入新架构（JSI + Fabric + TurboModules），将 JS 到 Native 的通信从异步 JSON 序列化改为同步 C++ 调用。2024 年 10 月 RN 0.76 将新架构设为默认^[10]。
2. Electron 让前端技术构建桌面应用成为可能。VS Code、Figma、Notion、Slack 全都基于 Electron。每个 Electron 应用都带一个完整的 Chromium 和 Node.js 运行时，代价是 150MB+ 的安装包和 500MB+ 的内存占用。Tauri（2022 年发布）试图用系统自带 WebView 替代 Chromium，把包体压缩到几 MB。
3. 微信小程序 在 2017 年创造了"超级 App 内的子应用"这个全新范式。支付宝、字节跳动、百度跟进推出各自的小程序平台。每个平台的 API 和 WXS/DSL 互不兼容，催生了 Taro、uni-app 等跨端编译框架。

2018 年 12 月 Flutter 发布 1.0 稳定版，用 Dart 语言和 Skia 渲染引擎绕过平台原生控件，实现了真正的"像素级一致"。2024 年 Flutter 3.22 的 Impeller 引擎在 iOS 上默认启用，解决了早期版本的"首次卡顿"问题^[11]。React Native 和 Flutter 的分野代表了跨平台的两条路线：前者拥抱平台原生控件（"learn once"），后者追求完全自主渲染（"write once"）。

主线推进：用户在不同设备上的体验第一次可以由同一支团队统一控制。支线推进：TypeScript 在 2020 年后成为前端事实标准；Vite 在 2021 年发布 2.0，用浏览器原生 ES Module 和 esbuild 把冷启动时间从分钟级降到毫秒级^[12]; Bun 在 2023 年发布 1.0，把运行时、打包器、包管理器合为一体；React Server Components 在 2023 年随 Next.js 13.4 App Router 进入稳定阶段。

5. 渲染架构的分化：SSR、SSG、ISR 与 RSC

到了 2020 年前后，SPA 的三个先天缺陷——首屏慢、SEO 差、JS 体积大——在内容型网站上变得不可容忍。Next.js、Nuxt、SvelteKit 这类元框架应运而生。它们的共同思路是：把渲染工作从浏览器提前到服务器（或者构建阶段），但保留 SPA 的客户端交互能力。

5.1 渲染策略光谱

构建时渲染 ←————————————————————————————→ 客户端渲染
   SSG           ISR          SSR         CSR
   (0 JS)      (按需)      (每次请求)     (全量JS)

• SSG（Static Site Generation）：构建时把整站预渲染成 HTML。首屏最快，CDN 友好。适合文档站、博客。Gatsby、Astro、Next.js 的静态导出模式都支持。
• SSR（Server Side Rendering）：每次请求在服务端动态渲染 HTML。适合需要个性化内容但不希望全量下发 JS 的场景。代价是 TTFB 比 SSG 高。
• ISR（Incremental Static Regeneration）：Vercel 在 2020 年提出的折中方案。页面在构建时生成，但可以在运行时按需重新生成。既保留了静态站的速度，又支持内容更新^[13]。
• CSR（Client Side Rendering）：经典 SPA。首次加载空白页，JS 接管一切。适合高度交互的应用（Dashboard、在线设计工具）。

除以上四种主流策略外，社区中还涌现了更多细分变体：ISG（Incremental Static Generation，增量静态生成）、NSR（Native Side Rendering，原生端渲染，先在客户端 Native 壳中渲染首屏）、DPR（Distributed Persistent Rendering，分布式持续渲染）、ESR（Edge Side Rendering，边缘端渲染，在 CDN 节点上完成渲染——本文第 6 节将详细讨论）。

2023 年 5 月，Next.js 13.4 的 App Router 将 React Server Components（RSC） 带入稳定阶段（RSC 于 2024 年 12 月随 React 19 成为 React 本身的稳定特性）。这个设计把组件分为两类：Server Component（在服务端渲染，不下发 JS）和 Client Component（在浏览器渲染，有交互）。关键是 Server Component 可以直接访问数据库和文件系统，不需要构建 API 端点。RSC 本质上是把 PHP 时代"服务端渲染组件"的思路，与 React 的组件化模型和对 Suspense 的流式支持结合起来^[14]。

5.2 渲染策略选择框架

没有一种渲染策略适合所有场景。Next.js App Router 允许你按路由选择 CSR/SSR/SSG/ISR，有时同一页面的不同组件采用不同策略。在内容型网站中，SSG + ISR 的组合通常是最优解；在 SaaS 后台中，CSR 搭配代码分割仍然硬朗。

主线推进：Core Web Vitals 从 2021 年开始影响 Google 搜索排名，渲染策略直接影响商业网站的流量和转化率。

6. Edge 渲染架构：把计算推到离用户最近的地方

核心矛盾：SSR 解决了首屏和 SEO 问题，但渲染服务器在 us-east-1，用户在东京、孟买、内罗毕。光速限制下，300ms 的 RTT 让 SSR 的理论优势打了折扣。

Edge 渲染的解决方案直接而有力：在 CDN 节点上运行渲染逻辑。Cloudflare Workers（2017）、Deno Deploy（2021）、Netlify Edge Functions（2022）、Vercel Edge Runtime（2022）相继出现。它们基于 V8 Isolate 技术，冷启动时间在 5-50ms 之间，不需要启动完整进程^[15]。Deno 团队早在 2021 年就断言"Web 的未来在边缘"，这一判断在五年后已被充分验证^[16]。

一个典型的 Edge 渲染流程：

根据公开数据，Edge 渲染可以将全球用户的 TTFB 降低 60-80%（相比单区域 Origin Server）^[17]。但这不是免费的午餐。Edge 节点的运行时环境受到限制：没有完整的 Node.js API，没有文件系统访问，不能维持长连接（如 Redis 连接池）。如果你的页面依赖集中式 Session 存储或复杂的数据库查询，Edge 渲染的优势会被回源延迟吞噬。

2025 年，Streaming SSR 搭配 Edge 成为主流方案。浏览器收到 HTML 的第一段字符后就开始解析 <head> 中的预加载指令，后台通过 Suspense boundary 逐步流式返回慢数据组件。用户感知的加载时间不再由最慢的组件决定，而是由 HTML shell 的到达时间决定^[18]。

主线推进：用户感知延迟从"秒级"进入"毫秒级"。支线推进：CDN 厂商（Cloudflare、Fastly、Akamai）将边缘节点从"静态缓存+简单逻辑"升级为"全功能计算平台"。

7. 群岛架构：把"该交互的"和"该静态的"分开运输

核心矛盾：大多数网页中，真正需要 JavaScript 的交互只占页面面积的 5-10%。但 SPA 和传统 SSR 都会把整页的 JS 发给浏览器。

Islands Architecture（群岛架构）由 Etsy 的 Katie Sylor-Miller 在 2019 年提出，Fred K. Schott 在 2021 年通过 Astro 框架实现。核心思想简洁：

• 页面的大部分是静态 HTML，不需要任何 JavaScript
• 只有少数独立区域（"岛屿"）需要交互——比如搜索框、评论区、购物车
• 每个岛屿是自包含的组件，甚至可以混合使用不同框架：导航栏用 React，评论区用 Vue，购物车用 Svelte

Astro 的 client:* 指令精确控制每个岛屿的水合时机：

指令	行为
client:load	页面加载后立即水合
client:idle	浏览器空闲时水合（requestIdleCallback）
client:visible	组件进入视口时水合（IntersectionObserver）
client:media	满足媒体查询时水合
client:only	跳过 SSR，仅客户端渲染

2024 年底 Astro 5 引入了 Server Islands：允许将需要个性化数据（用户头像、购物车数量）的岛屿延迟渲染。页面先发送包含占位符的完整 HTML，然后通过一个轻量的服务端请求填充个人化内容，无需等待整页重新渲染^[19]。

与群岛架构在哲学上相近但技术路线不同的是 Qwik。Qwik 提出了"可恢复性"概念：页面在 SSR 后不需要水合过程。当用户点击一个按钮时，Qwik 只加载该按钮对应的那一个事件处理函数（通过 $ 后缀标记的代码会被自动拆分为独立 chunk），在点击发生时从 CDN 拉取、执行，然后马上释放^[20]。

群岛架构的局限性也同样明确：大型开源组件库（如 Ant Design、Material UI）仍然为 SPA 框架设计，跨岛通信需要手动管理，迁移现有 SPA 比新建项目更难。

主线推进：JavaScript 发送量从 MB 级降到 KB 级。对于内容型网站，Lighthouse 评分从 50 分提升到 95 分以上只需要切换渲染策略，不需要重新设计页面。

8. 五条支线的演进地图

前面七个小节沿着架构范式的主线展开。下面对五条支线做横向扫描，理解为什么每次架构跃迁能够发生。

8.1 硬件性能

年代	代表性硬件	对前端的影响
1995-2000	Pentium, 32-64MB RAM, 56K Modem	任何超过 50KB 的页面都要等待数秒
2005-2010	Core 2 Duo, 2GB RAM, 1-2Mbps DSL	Ajax 请求的延迟在 200ms 以内，动态页面成为可能
2015-2020	多核 CPU, 8GB RAM, 4G/LTE	SPA 框架的虚拟 DOM diff 计算在设备上无压力运行
2020-2025	Apple M1, 16GB+, 5G, Wi-Fi 6	Edge 节点全球分布、Wasm 在浏览器中运行接近原生速度

用户设备的平均 CPU 单核性能在过去 20 年提升了约 100 倍^[21]。这让框架可以承受虚拟 DOM 这种"用计算换开发效率"的设计。

8.2 JavaScript 引擎

2008 年 V8 的 JIT 编译是分水岭。在 V8 之前，JavaScript 被当作脚本语言解释执行，性能比 C 慢 100-1000 倍。JIT 编译器根据运行时类型信息生成机器码，在热点路径上达到了 C 代码 2-5 倍的性能差距。SpiderMonkey（Firefox）、JavaScriptCore（Safari）随后跟进^[22]。

编译优化并非一帆风顺。V8 的优化编译器经历了 Full-Codegen（2010）→ Crankshaft（2010）→ TurboFan（2015）→ Sparkplug + Maglev + TurboFan 三级分层（2022+）。每次重写都是为了解决上一代编译器在特定场景下的性能悬崖——比如你的代码在 Crankshaft 下跑得飞快，加一行 try-catch 后性能降到原来的 1/20^[23]。

2017 年 WebAssembly MVP 发布。这是 C/C++/Rust 代码直接在浏览器沙箱中运行的第一个标准化方案。Figma 用 Wasm 把 C++ 渲染引擎搬进浏览器，加载时间从 4 分钟降到 30 秒。AutoCAD Web 用 Wasm 把桌面级 CAD 内核移植到 Chrome 中。在国内，B 站使用 WebAssembly 在浏览器中软解 HEVC 视频，避免了依赖设备硬解能力的兼容性问题^[24]。

8.3 语言演进

• HTML：从 HTML 2.0（1995）到 HTML5（2014），新增了 <canvas>、<video>、<audio>、Semantic Elements（<article>、<nav>、<section>）。HTML Living Standard 从 2019 年起不再发布版本号，改为持续更新。
• CSS：从 CSS1（1996，字体颜色背景）到 CSS3（2011，动画、过渡、渐变、Flexbox、Grid），再到 2023-2025 年的现代 CSS 特性：:has() 选择器（"父选择器"）、container queries（容器查询）、nesting（嵌套）、@layer（层级控制）。Tailwind CSS 在 2017 年诞生的背景是 CSS 全局作用域导致的维护困难，而现代 CSS 内置的 @scope 和 @layer 正在从根本上解决这个问题。
• JavaScript：ES6（2015）之后的年度发布节奏让语言持续进化。async/await（ES2017）、Optional Chaining（ES2020）、Top-level await（ES2022）、Temporal（2017年提案，2021年进入 Stage 3，2026年3月进入 Stage 4，将随 ES2026 正式发布）等特性每次都在消除对第三方库的依赖。
• TypeScript：微软在 2012 年发布 TypeScript，2014 年发布 1.0。到 2024 年，npm 下载量中 TypeScript 相关包占比超过 30%^[25]。类型系统从简单的类型注解演进到 Template Literal Types、Conditional Types、satisfies 运算符、const generics。TypeScript 对前端工程化的意义不在于"防止 bug"（虽然确实有帮助），而在于让 IDE 的自动补全、重构、跳转定义变得可靠。

8.4 构建工具链

年代	工具	痛点
2009-2012	Grunt, Gulp	任务配置冗长，插件质量参差不齐
2014-2018	Webpack	配置地狱，构建慢
2018-2020	Rollup, Parcel	Rollup 适合库，Parcel 零配置但生态弱
2021-2023	Vite, esbuild, SWC	Vite 利用 ESM 实现毫秒级 HMR
2023-2025	Turbopack, Rspack, Rolldown	Rust 重写的打包器，速度再提升 10-50x

Vite 的设计抓住了两个关键变化的窗口期：浏览器原生 ES Module 支持率达到 90%+，esbuild 证明了 Go 写的打包器可以比 JS 写的快 100 倍。开发模式下 Vite 不做打包，改动的模块通过浏览器原生 ESM 直接加载。生产模式下用 Rollup（Vite 4-5）或 Rolldown（自 Vite 8 起作为默认打包器，Rust 实现）做 tree-shaking 和代码分割。

Rolldown 在 2025 年底随 Vite 8 beta 成为默认打包器，2026 年 5 月达到 1.0 稳定版，在大型项目上的生产构建速度相比 JS 打包器有数量级提升^[26]。swc 和 Turbopack 用 Rust 实现，Rspack 用 Rust 实现且兼容 Webpack 配置和 loader 生态。

8.5 框架灵活性的螺旋上升

观察框架的演进方向能发现一个螺旋：

1. jQuery 时代：库极小（30KB），不限架构，但代码组织完全靠纪律
2. AngularJS/Ember 时代：框架高度规范，但"意见"太多，不够灵活
3. React 时代：库而非框架，只负责视图层，路由/状态管理/数据获取靠生态
4. Next.js/Nuxt 时代：框架重新收回控制权，规范文件路由、数据获取、渲染策略
5. Astro 时代：框架只管构建和路由，UI 层面允许混合使用多种框架

每一步都是对前一步过度矫正的回应。React 因为太灵活导致社区在"最佳实践"上分裂了五年（Redux vs MobX、Saga vs Thunk、Class vs Hooks、CSR vs SSR），Next.js 收紧了选择空间后开发者效率反而提升。Astro 则在元框架收紧的方向上往回收了一步，允许内容团队用 .astro 组件，交互团队用 React/Vue/Svelte，各取所需。

9. 2026 年的技术栈推荐

以下推荐基于 2025 年 State of JavaScript 调查和实际项目经验，按场景分类^[27]：

场景	推荐技术栈	理由
内容型网站（博客/文档）	Astro + Markdown/MDX + 少量 React/Vue 岛屿	零 JS 默认，需要时按需水合
SaaS 中后台	Next.js App Router + React + tRPC/Drizzle + Tailwind	RSC 减少 bundle，全栈类型安全
高交互 SPA	Vite + React Router + TanStack Query	极快 HMR，类型安全路由和数据获取
小程序/跨端	Taro 3.x + React/Vue 或 uni-app	一套代码编译到微信/支付宝等多平台
桌面应用	Tauri v2 + React/Vue + Rust（性能敏感模块）	安装包 < 10MB，比 Electron 内存减少 50-80%
移动端	React Native 新架构 或 Flutter	根据团队 JS/Dart 技术栈和原生交互需求决定

没有银弹。选择架构的唯一有效标准是：用最少的 JavaScript 和最少的运行时复杂度满足用户的交互需求。

10. 总结

回头看三十五年，前端发展遵循三条规律：

1. 架构范式的跃迁由硬件和网络能力解锁。没有 2008 年的 V8 JIT，就没有 2013 年的 React 虚拟 DOM。没有 2020 年的全球 CDN Edge 节点和 V8 Isolate，就没有 2024 年的 Edge SSR + Streaming。
2. 每次架构创新都在"开发者体验"和"用户体验"之间寻找纳什均衡。SPA 牺牲了首屏速度换取了开发效率，SSR 恢复了首屏速度但增加了运维复杂度，群岛架构在内容型网站上实现了双赢，但在高交互场景下优势有限。
3. 工具的演进永远是"复杂度守恒"。你可以在框架层省下的心智负担，迟早会在构建配置、部署策略、运行时调试中以另一种形式出现。Rust 重写的构建工具（Turbopack、Rolldown）用编译速度换来了理解成本——调试一个 Rust 写的打包器的内部行为比调试 Webpack 配置更难。

前端不会停止演化。WebAssembly GC 在 2024 年达到 Phase 4（标准化完成），View Transitions API 在 2025 年进入跨浏览器支持阶段。WebCodecs API 让浏览器可以直接编解码音视频流，WebTransport 提供了比 WebSocket 更低延迟的传输通道，WebGPU 将现代图形 API 的算力暴露给 Web 应用^[28]。CSS 的能力还在以每年一批新特性的速度增长。但核心问题始终没变：你如何用更少的字节、更少的计算、更少的时间，把信息更清晰地传递到用户面前。

参考文献

---

1. Riad Kilani, "Evolution of Front-End Development (2010–2025)", 2025年8月. https://blog.riadkilani.com/evolution-of-front-end-development-2010-2025 ↩︎

2. TSH.io, "How Modern Frontend Development Has Evolved (2020-2024)", 2024年11月. https://tsh.io/blog/how-modern-frontend-development-has-evolved ↩︎

3. 维基百科：SGML. https://en.wikipedia.org/wiki/Standard_Generalized_Markup_Language ↩︎

4. 维基百科：WorldWideWeb. https://en.wikipedia.org/wiki/WorldWideWeb ↩︎

5. W3C, "The Original HTTP as defined in 1991". https://www.w3.org/Protocols/HTTP/AsImplemented.html ↩︎

6. Brendan Eich, "A Brief History of JavaScript", 2020. https://brendaneich.com/ ↩︎

7. Jesse James Garrett, "Ajax: A New Approach to Web Applications", Adaptive Path, 2005年2月. https://adaptivepath.org/ideas/ajax-new-approach-web-applications/ ↩︎

8. W3Techs, "Usage Statistics of JavaScript Libraries". https://w3techs.com/technologies/overview/javascript_library ↩︎

9. Google, "A Brief History of V8", V8 Blog. https://v8.dev/blog/10-years ↩︎

10. React Native 团队, "The New Architecture", 2023. https://reactnative.dev/docs/the-new-architecture/landing-page ↩︎

11. Flutter 团队, "Impeller Rendering Engine", 2024. https://docs.flutter.dev/perf/impeller ↩︎

12. Evan You, "Vite: Next Generation Frontend Tooling", 2021. https://vitejs.dev/ ↩︎

13. Vercel, "Incremental Static Regeneration", 2020. https://nextjs.org/docs/pages/building-your-application/data-fetching/incremental-static-regeneration ↩︎

14. React 团队, "React Server Components", 2023. https://react.dev/reference/rsc/server-components ↩︎

15. Netguru, "Frontend Trends 2026: Edge Rendering and Streaming SSR", 2025. https://www.netguru.com/blog/front-end-trends ↩︎

16. Deno Blog, "The Future of the Web is on the Edge". https://deno.com/blog/the-future-of-web-is-on-the-edge ↩︎

17. 同上. 引用 Hashmeta 2024 年研究数据. ↩︎

18. Next.js 文档, "Streaming". https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming ↩︎

19. Astro 文档, "Server Islands", 2024. https://docs.astro.build/en/guides/server-islands/ ↩︎

20. Qwik 文档, "Resumability vs Hydration". https://qwik.dev/docs/concepts/resumable/ ↩︎

21. CPU Benchmark 数据来自 PassMark Software. https://www.cpubenchmark.net/ ↩︎

22. V8 团队, "How V8 Measures Real-World Performance", 2023. https://v8.dev/blog/real-world-performance ↩︎

23. V8 Blog, "TurboFan: A New Code Generator for V8", 2015. https://v8.dev/blog/turbofan ↩︎

24. WebAssembly 软解 HEVC 在 B 站的实践. https://www.bilibili.com/read/cv16257864/ ↩︎

25. npm Trends, "TypeScript vs JavaScript Download Statistics". https://npmtrends.com/typescript ↩︎

26. VoidZero, "Announcing Rolldown 1.0", 2026年5月. https://rolldown.rs/ ↩︎

27. State of JavaScript 2025 Survey. https://stateofjs.com/ ↩︎

28. WebGPU API 规范. https://www.w3.org/TR/webgpu/ ↩︎