为什么我们在浏览器里渲染一切

打开任何一个现代网站——水电公司的登录页、餐厅预订系统、快递追踪界面——你的笔记本风扇开始狂转，只为渲染几行文字。2025年的网页中位数，在首个字符可见之前，已经塞了697KB的JavaScript。浏览器被迫做着1996年服务器就能完成的工作，而且是在电池供电、流量计费、机身烫到能煎蛋的设备上。

这就是本文要聊的事。

这种惯性无处不在。每个新项目都以前端框架起手，搭构建流水线，配打包工具，设计注水策略。服务器——数据原本就在那儿——被降级成JSON水龙头。渲染成了浏览器的麻烦。没人记得这是什么时候定下来的。

其实没有哪场会议、哪次争论拍板了这个决策。它是层层叠加的结果。每个项目选这个框架，因为上一个项目用了；每个开发者学这个框架，因为招聘启事这么写。等有人想质疑这个前提时，它早已固化为架构、课程表、会议议程、招聘漏斗。2026年要是有人想写服务器渲染的页面，很多工程师会觉得像在用COBOL：技术上说得通，职业上可疑。

这种"感觉"才是本文真正的主题。

2005年，AJAX登场。Jesse James Garrett在那篇著名文章里命名了这个模式，描述Gmail和Google Maps如何用异步XMLHttpRequest局部更新页面、避免整页刷新。技术是真的，收益是真的，但适用场景很窄：用户一待几小时、单次会话交互上百次的"应用"。

2010年Backbone问世（Jeremy Ashkenas），同年Angular（Misko Hevery、Adam Abrons），2011年Ember，2013年React（Facebook的Jordan Walke）。每个都是真诚回应真实问题：浏览器里的桌面级应用，确实需要客户端状态管理、视图差分、离线容错。Gmail、Google Maps、Figma——真应用，真需求。

然后这个模式蔓延到了所有"不是Gmail"的网站上。营销页、企业官网、餐厅菜单、政府表单、区域铁路订票、诊所预约。支撑Gmail架构的理由，从未被重新审视是否适用于企业官网——因为重新审视需要的那套技能，和搭官网本身所需的技能完全不同。到2018年，单页应用（SPA）已被视为Web默认架构。到2020年，"我先起个Next.js项目"成了静态内容的条件反射式起手。

转变不是理论层面的，是招聘层面的。一代前端开发者在训练营学了React，然后一份工作、又一份工作，从没学过服务器语言。简历上有React才能拿到面试；没人招"懂session cookie是什么"的人。TypeScript作为本地补丁登场：一个编译时包装层，试图弥补……