20 年前端演化史被一篇文章讲清楚了：从 jQuery 到 AI 辅助，我们的工具为什么越来越重，又为什么开始变轻

20 年前端演化史被一篇文章讲清楚了：从 jQuery 到 AI 辅助，我们的工具为什么越来越重，又为什么开始变轻

导语

你有没有这种感觉：2008 年你写个网页，保存、拖进 FTP、就能跑；2026 年你新建一个前端项目，光 node_modules 就 14 万个文件，构建工具比你的业务代码还长。最近两篇文章把这件事讲透了：一篇回顾了前端 20 年是怎么一步步”变重”的，另一篇则在 AI 编程时代反问：我们还应该亲手写代码吗？ 看完我意识到，答案可能不是”写”或”不写”，而是”怎么理解你正在写的系统”。

正文

问题：前端为什么变得这么复杂？

先看一组时间线：

• 2006-2010（4MB 时代）：你只是想局部刷新页面，jQuery 用 $("#cart").load(...) 解决了浏览器兼容噩梦。AJAX 成了标配，黄金年代。
• 2010-2015（9MB 时代）：应用变复杂了，手动同步数据到 UI 让你崩溃。React 2013 年出现，用声明式 UI 解决了”数据变了界面忘了更新”的问题。一个 <button> 从 22 字节变成了需要 React 运行时 ~45KB 的组件。
• 2012-2018（15MB 时代）：模块系统打架（CommonJS vs ESM）、浏览器看不懂 JSX，Babel + Webpack 出现了。node_modules 成了宇宙最重物体。
• 2018-2024（21MB 时代）：构建太慢了。esbuild（Go）把速度提高了 50-100 倍，Vite 成了默认选择，SWC 替代 Babel，Rolldown 正在接管 Vite 的生产打包。
• 2014-2026（28MB 时代）：服务端渲染回来了。SSR、SSG、RSC、Islands 架构——本质上是 2008 年的服务端渲染，但带了一堆新缩写。

David Poblador 在《The Descent》里说了一句很精准的话：“Every tool is scar tissue grown over a real wound.” 每个工具都是为了修复上一个工具带来的问题，而修复本身又创造了下一个问题。

一个 <button> 的 20 年

2008 年的版本：

<button class="buy">Buy</button>
<style>
  .buy { padding: 4px 10px; border: 1px solid #999; }
</style>
<!-- 0 依赖，0 构建，所有浏览器直接跑 -->

2026 年的版本：

function Buy() {
  return (
    <button onClick={addToCart}>
      Buy
    </button>
  )
}
// 需要：React 运行时、构建步骤、模块解析器、JSX 转译器
// 最小交付：~45KB runtime + 构建配置

同一个 <button>，从”浏览器原生理解”变成了”需要一整套基础设施才能渲染”。

方案：2026 年的回摆

现在行业正在往回走，但带着 20 年积累的经验：

1. 服务端渲染回归

RSC、SSR、SSG、Islands 架构本质上是”把 HTML 先吐出来”，和 2008 年的 PHP 模板异曲同工，但现在的实现更精细，支持流式、选择性水合。

2. 工具链 Rust/Go 化

esbuild、SWC、Rolldown、Oxc 用 Rust/Go 重写，速度提升 50-100 倍。VoidZero 被 Cloudflare 收购后，Vite 生态正走向统一。

3. 轻量框架抬头

htmx、Alpine.js、Hotwire 说：”我们能不能不离开服务器？” 2026 年这个阵营声音越来越大。

4. AI 辅助编程改变了什么？

Doug Turnbull 在《Why Write Code in 2026》里说了一个反常识的观点：即使 AI 能生成代码，亲手写代码仍然重要。

原因不是”AI 写得不好”，而是：

• 写代码是理解系统架构最直接的方式
• AI 像” freshly onboarded interns”，会放大你的一次性错误决策
• 你需要建立”软件工厂”，而不只是某个部件的代码

可落地的判断标准

如果你现在站在技术选型路口，可以参考这个清单：

下一步：建立你自己的” scar tissue “地图

下次遇到新工具，先问三个问题：

1. 它解决了什么具体问题？
2. 上一个工具带来了什么痛点，才导致这个新工具出现？
3. 如果我不用这个工具，最坏的情况是什么？

大多数情况下，你会发现”最坏的情况”并没有那么糟，而新工具带来的复杂度往往被低估。

—

参考来源：

• David Poblador, “The Descent — What Happened to the Frontend While You Weren’t Watching” (2026-07-12)
• Doug Turnbull, “Why Write Code in 2026” (2026-07-09)
• Coder.talk 聚合站摘要