引言: 带着2008年的知识打开2026年的代码库

如果一个2008年前后离开前端开发的人,今天打开一个2026年的代码库,陌生感几乎是必然的。那一年的标配是jQuery、刚刚摆脱表格布局的CSS,以及每次请求都由服务器重新渲染整页的「整页刷新」模式。今天完全不同了: TypeScript成了默认配置,构建工具几秒钟就能启动,组件按文件粒度声明自己该在服务器端还是客户端运行,而代码本身有相当一部分是AI代劳完成的。

本文梳理这20年的变化。我按时代顺序整理每一次转折「为什么」发生——出现了什么问题、催生了什么方案、这个方案又带来了什么新问题——并给出一份实用建议: 如果现在要回归前端,应该先学什么。这是我自己整理的回顾,先说结论: 工具一直在变,但问题的形态却惊人地重复。看清这种重复,是回归学习最快的捷径。

1. 2008年 - jQuery与服务端渲染的时代

1.1 刚刚摆脱表格布局的CSS

2008年的Web仍处于浏览器割裂的时代。IE6在企业环境中大行其道,用表格标签搭建布局的做法尚未完全消失,正逐渐过渡到基于float的CSS布局。响应式设计这个概念当时根本不存在——媒体查询成为标准做法还要再等几年。

1.2 jQuery解决了什么问题

在这样的环境下,2006年发布的jQuery堪称救星。它把DOM操作、事件处理,以及各浏览器行为不一致的XMLHttpRequest,统一包装进一套API。链式写法把跨浏览器兼容地狱抽象掉了,同时普及了AJAX,把「只刷新页面局部」的模式带入日常实践。但状态与画面的同步仍然是开发者自己的活——数据一变,就得手写命令式代码,逐一指明该改动哪个DOM节点、怎么改。

2. 2010~2013年 - 框架登场: Backbone与AngularJS

2.1 命令式DOM操作的局限

随着应用规模变大,jQuery代码很容易变成一团意大利面——很难追踪到底是哪里、什么在改动画面。针对这个问题的答案,几乎同时在2010年10月出现: Backbone.js(Jeremy Ashkenas)和AngularJS(Google)。

2.2 MV*模式与数据绑定

Backbone强制采用模型-视图结构,把状态和画面分开,但DOM更新依然是开发者直接命令式指定。AngularJS更进一步,主打双向数据绑定——模型变了画面跟着变,表单输入变了模型也跟着变。2012年AngularJS 1.0正式发布后,这套思路被广泛采用。不过它内部的更新循环——摘要循环(digest cycle)——在应用规模变大后开始引发性能问题。

3. 2012~2014年 - TypeScript,以及React、Vue的登场

3.1 TypeScript的低调起步

2012年10月,微软在Anders Hejlsberg(C#与Turbo Pascal的设计者)主导下发布了TypeScript。它是在JavaScript之上叠加静态类型的超集语言,但早期反响冷淡——IDE支持不足,也没多少开发者觉得有必要额外增加一道编译步骤。直到2018年,按开发者调查数据,其使用率仍未突破10%。

3.2 React登场,带来声明式UI

2013年,Facebook开源了React。核心是虚拟DOM、组件化架构,以及把标记与逻辑混写在同一文件中的JSX。开发者不再声明「如何改变」画面,而是声明「如果当前状态是这样,画面就应该长这样」,由React自己去计算实际的DOM更新。2014年,尤雨溪推出了兼取Angular与React之长的Vue.js,进一步拓宽了选择面。从这时起,前端的重心从「命令式操作DOM」转向「声明式描述状态」。

4. 构建工具之战 - 从Webpack到Vite

4.1 为什么需要构建步骤

浏览器无法直接理解JSX和ES6+语法,再加上「分模块开发、合并打包后再发布」的需求,两者叠加在一起。Babel负责转译,Webpack负责打包,从2010年代中期开始,这套组合事实上成了标准配置。代价也随之而来——配置文件越来越复杂,node_modules目录膨胀到几十万个文件,开发服务器启动动辄数十秒到几分钟的项目也变得常见。

4.2 esbuild、SWC、Vite - 用原生语言重写

进入2020年代,「编译太慢」这个问题本身催生了新的解决方案。用Go写的esbuild、用Rust写的SWC,编译速度比用JavaScript写的旧工具快几十到几百倍。同一年,尤雨溪再度出手推出Vite(2020): 开发阶段直接利用浏览器原生的ES模块加载,真正的打包只在部署时交给Rollup处理,几乎把开发服务器的启动时间压缩到「瞬间」。截至2026年7月,相当一部分新项目选择用Vite或以其为基础的框架起步,而不是Webpack。

5. TypeScript,从可选到标配

5.1 转折点

TypeScript的翻身,始于各大框架直接将其采纳为官方语言。2016年Angular 2把TypeScript定为官方编写语言,2020年Vue 3索性把整个代码库用TypeScript重写。再加上像严格空值检查(strict null checks)这样的实质性安全保障不断加码,采用速度随之加快。

5.2 如今是默认选项

专业开发者的使用率从2020年的约34%,一路升到2025年的约73%、2026年的约78%,2025年TypeScript还首次超过JavaScript,成为GitHub上使用最多的语言。Next.js、Nuxt、SvelteKit等主流框架现在新建项目时都默认配置TypeScript。对回归的开发者来说,这大概是最显眼的变化——「只懂JavaScript就够了」这个前提本身已经过时。

6. SPA的反作用力 - 服务端渲染的回归

6.1 SPA带来的新问题

用React、Vue搭建的SPA(单页应用)页面切换很流畅,但也带来了新问题。首次加载时,用户拿到的只是一个空的div,要等JavaScript下载并执行完才能看到内容,期间只能盯着白屏。当年的搜索引擎也常常读不懂这种空白页面,对SEO不利。

6.2 Next.js、Nuxt与元框架的崛起

2016年10月,Next.js(当时属于Zeit,现在的Vercel)以「在React之上叠加服务端渲染(SSR)和静态站点生成(SSG)」的元框架身份登场。Vue阵营的Nuxt.js也抱着同样的问题意识。做法回到了「服务器先送出完整HTML,再由JavaScript在其上挂载交互」——这与2008年的服务端渲染方式颇为相似,不同之处在于这一次可以按组件粒度、而不是整页静态页面,在服务器和客户端之间切换。

7. 组件与设计系统

随着组件化架构落地,「如何管理可复用的UI片段」成了新课题。早期以Bootstrap、Material UI这类「整体安装」的组件库为主流。近来,像shadcn/ui这样「不把库当依赖安装,而是把组件代码直接复制进项目」的方式开始流行,理由是不增加打包体积、完全拥有代码、可以随意修改。设计系统也随这股潮流一起落地——把色彩、间距、排版做成token,与组件库绑定,在多个产品间保持一致的UI,这已经成为常规做法。

8. 状态管理的变迁 - 从Redux到Zustand、Signals

8.1 Redux称霸的年代

随着React生态壮大,「这份状态由谁持有、由谁修改」的问题逐渐凸显。Redux(2015年,Dan Abramov与Andrew Clark)把Facebook在2014年提出的单向数据流模式Flux落地成实用方案,事实上成了标准。它带来了可预测的状态变化、时间旅行调试等优点,但action、reducer、dispatch这一整套样板代码,哪怕只是一个小功能也要新建三四个文件,这类抱怨一直没停过。

8.2 Hooks之后 - Zustand与服务端状态的分离

2019年React Hooks登场后,函数组件也能处理状态和副作用,不依赖Redux也能充分管理本地状态。与此同时,「从服务器取来的数据」和「只存在于客户端的UI状态」应该区分对待的认识逐渐普及——前者交给TanStack Query这类专门的服务端状态库,后者交给Zustand这种没有样板代码的轻量store,这条分工路线逐渐固定下来。2023年到2025年间,Zustand的使用占比从28%跃升到50%,按下载量已经超过Redux。

8.3 Signals,尚未真正到来的下一个范式

由SolidJS、Preact普及开来的Signals,是一种精细响应式模型: 某个值一变,只有订阅了这个具体值的地方才会重新计算。Angular近期版本也引入了基于signal的响应式机制。不过在JavaScript标准层面,TC39的Signals提案截至2026年初仍停留在第一阶段——按流程要先在多个框架里经过实战验证,才能进入下一阶段,这是一套偏保守的审议节奏。既然标准化尚未完成,把Signals看作「已经在多个框架中各自实现的一种实用模式」,比看作「下一代标准」更准确。

9. CSS的演化 - 从Sass到CSS-in-JS、Tailwind,再到原生CSS

CSS也经历了同样的循环。为弥补「没有变量、没有嵌套」的CSS局限,Sass、LESS这类预处理器一度成为标配。React把组件化开发标准化之后,「样式也应该绑定到组件上」的需求随之出现,2016年出现的styled-components等CSS-in-JS方案给出了答案。之后在2017年末发布的Tailwind CSS(Adam Wathan)又把方向拧了回来——不再另写CSS文件,而是把预先定义好的工具类直接写进标记语言里,省下了纠结类名和在样式文件间来回切换的时间。而截至2026年7月,Sass、Tailwind曾经填补的空白,相当一部分已经被CSS原生功能本身吸收——嵌套(nesting)在全球浏览器中的支持率超过90%,CSS变量(自定义属性)超过97%,容器查询超过93%。预处理器曾经解决的许多问题,如今已经变成了平台自带能力。

10. React Server Components、边缘计算与水合之争

就算回归了SSR,新问题依然存在。即便服务器已经渲染出HTML,要让画面真正具备交互性,浏览器仍需重新执行一遍同一套组件树,挂载事件监听器——这个过程就是「水合(hydration)」。相当于在服务器和客户端各做了一遍几乎相同的渲染工作,拖慢了包体积和首次可交互时间。

2020年底React团队首次展示的React Server Components(RSC),用另一种方式解决了这个问题——可以按文件粒度指定「只在服务器运行、JavaScript代码本身根本不会发往客户端」的组件。2023年Next.js的App Router把它设为默认选项,才真正走入实战。截至2026年,业内的做法大致是: 没有交互的UI作为RSC只留在服务器端,只有真正需要点击、输入的部分才作为客户端组件,从而缩小需要水合的范围。与此同时,Vercel、Netlify、Cloudflare等平台开始在边缘节点运行服务端组件,把延迟拉近到用户身边,「一次git push就能完成部署」也变得理所当然。

11. 2026年现状 - AI编程与框架疲劳

这20年的最后一层变化,不在工具本身,而在「写代码」这件事的方式上。2021年GitHub Copilot把自动补全级别的AI结对编程带入大众视野后,这条线继续延伸到把提示词或截图转成React+Tailwind+shadcn/ui代码的v0、Cursor这类AI原生编辑器,以及能在终端里自主修改多个文件的Claude Code这类智能体式工具。截至2026年7月,一种常见的工作方式是: AI先快速给出UI草稿,路由、状态、测试这类需要判断的部分则由开发者来打磨完善。

与此同时,反作用力也很明显。打包工具、代码检查工具、monorepo工具、测试运行器不断被替换,让一部分开发者感到疲惫,「框架疲劳」这个说法又重新被提起,也有报道显示部分开发者选择放弃框架,回归原生JavaScript或浏览器原生API。随着React 19趋于稳定、Svelte 5广受好评,一度被称为「框架战争」的竞争格局,也有评价认为已经进入了阶段性的休战状态。

12. 写给回归开发者的实用路线图 - 该先学什么

如果带着2008年的知识打开2026年的代码库,我建议的顺序如下。

先学TypeScript。它现在不是可选项,而是大多数项目的默认语言。如果已经懂JavaScript语法,叠加类型语法只需要几天。

把React或Vue其中一个学扎实。不要试图同时学两个框架,把组件、props、状态、副作用这些概念在一个框架里学深学透,换到另一个框架时大约八成可以直接迁移。

用元框架真正部署一次。不管选Next.js还是Nuxt,都挑一个实际上线,这是建立路由、数据请求、服务端/客户端组件边界这些直觉最快的办法。

熟悉Tailwind CSS的工具类写法。这不代表要忘记CSS本身,而是说实务中遇到的代码很可能大多是这种写法。

状态管理从简。不必一开始就学Redux,React自带状态加Zustand之类的库就能覆盖大多数实际工作,只需理解「服务端数据交给专门的数据请求库处理」这个概念即可。

构建工具浅尝即可。知道Vite在背后替你处理了大部分细节,对日常工作就已经足够。

把AI编程工具当工具用。不要照单全收Cursor或Claude Code给出的代码,能解释「为什么这么写」这条原则,20年前和现在同样重要。

13. 框架疲劳时代,基础功的价值

有意思的是,工具越花哨,最后留下来的反而是那些古老的基础知识。DOM是什么、事件循环怎么运转、HTTP请求与响应之间交换了什么、浏览器如何解析HTML生成渲染树——这些知识在jQuery时代、React时代,乃至今天AI代写部分代码的时代,都没有变过。框架的语法每换一次工具就得重新学一遍,但对Web平台本身的理解无论换用什么工具都能继续带着走。这正是2008年学前端的开发者占优势的地方——那时候没有框架替你遮住这些基础,所以反而不得不把基本功刻进身体里。

结论 - 20年的循环,以及下一个20年

如果用一句话概括前端从2008年走到2026年的历程,那就是: 每个时代的解决方案催生了下一个时代的问题,而这个问题又召唤出新的解决方案,如此循环往复。jQuery的命令式DOM操作演变成框架的声明式UI,框架带来的构建复杂度催生了Vite这类高速工具,SPA制造的白屏问题带来了服务端渲染的回归,而这次回归又带来的水合开销,最终引向了服务端组件。

截至2026年7月,下一轮循环的候选已经浮现——AI生成代码的维护负担,以及作为「框架疲劳」反作用力而出现的「回归简单」趋势。对20年前离开前端的人来说,这些名词大多陌生,但陌生的只是工具的表层,底下反复出现的「问题-方案」结构,其实相当眼熟。

参考资料

David Poblador - What Happened to the Frontend: davidpoblador.com

GeekNews 讨论: news.hada.io

LogRocket - History of front-end frameworks: blog.logrocket.com

The GitHub Blog - TypeScript's rise in the AI era: github.blog

Redux 官方 - The History of Redux: redux.js.org