2008 年做一个网页，很多时候就是写 index.html，改一点 CSS，用 FTP 拖上服务器。
没有构建。没有依赖树。浏览器打开，页面就在。
现在，一个按钮可能要穿过 JSX、TypeScript、Babel 或 SWC、打包器、框架运行时、服务端渲染，再在浏览器里 hydration 一遍。一个 node_modules 文件夹，足够把人从“我会写网页”按回“我是不是漏学了十年”。
那篇面向手写 HTML 时代开发者的前端长文，最有价值的地方不在吐槽。它把这堵墙一块块拆开：每一块砖，最初都不是为了折磨人。
前端二十年，复杂度从哪里来
前端不是从简单直接跳到混乱。它更像一串补丁史。
每一代工具都在修上一代的痛点，也顺手留下新成本。
| 阶段 | 当时要解决什么 | 留下的代价 |
|---|---|---|
| jQuery / AJAX | 不刷新整页，也能更新局部页面 | 手动同步 DOM，项目一大就乱 |
| React / Vue / Angular | 用数据驱动界面，少写命令式 DOM 操作 | 组件、状态、运行时进了浏览器 |
| Babel / webpack | 写新语法、拆模块、兼容旧浏览器 | 构建步骤和依赖管理成了日常 |
| esbuild / SWC / Vite / Rust 工具链 | 构建太慢，开发体验太痛 | 工具更快，但栈更厚 |
| SSR / SSG / ISR / RSC | 白屏、SEO、首屏性能和服务端数据压力 | 又回服务器，但带着新约束 |
几个词要压缩讲清。
声明式 UI，是你不再写“找到这个按钮，改它文字”，而是写“数据是这样时，界面应该长这样”。
组件，是把结构、行为、状态封成可复用的小块。
构建步骤，是把新语法、模块、样式、资源处理成浏览器能吃的东西。
真正让人刺痛的，是 hydration tax。
服务器先把 HTML 做好发给用户，页面看起来已经出现了。但按钮还没真正接上事件。浏览器还要下载 JS，再跑一遍，让页面“活过来”。
饭在厨房做了一遍，到桌上还要再做一遍。
所以才有 Astro 的 islands：只唤醒页面里少数需要交互的岛。Qwik 讲 resumability：尽量跳过传统 hydration。React Server Components 则把一部分组件留在服务器，只把必要交互送到客户端。
这不是简单倒退到 2008。
它是回到服务器，但背着二十年的框架债、性能债和产品野心。
每一层工具，都是伤疤
我不太买账那种“现代前端全是过度工程”的骂法。
爽，但不准。
jQuery 不是闹着玩的。早年浏览器差异大，DOM API 难用，AJAX 改变了网页体验。
React 也不是凭空造神。它解决了手动同步 UI 的根本痛点：数据变了，界面怎么稳定跟着变。
webpack、Babel 的出现，是因为 JavaScript 语言、浏览器兼容、模块体系长期欠账。Vite、SWC、esbuild 这一波提速，则是因为上一代工具真的慢到影响工作流。
像铁路早期的标准混战：先扩张，后治理，成本最后藏进基础设施。前端也差不多。轨道铺出来了，城市连起来了，但后来每个人上车前，都得先学轨距、信号灯和调度规章。
这里的反常点在于：工具本来替人挡复杂度，后来复杂度变成了人的入门考试。
一个内容页、一个表单、一个轻后台，也常被默认塞进同一套重型流水线。问题不在框架存在，而在行业太容易把大厂伤口当全民体检报告。
另一条路一直在。
htmx、Alpine、Hotwire、Astro 这类“少发 JS、让 HTML 回到中心”的路线，不是怀旧党自娱自乐。它们提醒前端一件朴素的事：网页的默认能力，比很多框架叙事里说的要强。
但它们也不是万能药。
复杂协作、重交互状态、跨团队复用、长期重构，仍然需要约束。少发 JS 不等于少设计。回到 HTML，也不等于回到无成本。
分水岭不是会不会用框架
离开前端多年的人，补课不该从背工具名开始。
更该补的是判断力。
你要先问三件事：页面需要多少交互？首屏和 SEO 有没有硬要求？团队有没有能力长期维护这套复杂度？
| 你在做什么 | 更合理的起点 | 需要警惕什么 |
|---|---|---|
| 内容站、文档、营销页 | 静态生成、Astro、少量交互岛、简单服务端模板 | 为了一个订阅按钮引入整套 SPA |
| 表单、轻后台、小工具 | 服务端渲染、Hotwire/htmx/Alpine、少量组件化 | 把简单 CRUD 做成状态管理练习题 |
| 高交互应用 | React/Vue/Angular、TypeScript、完整构建链 | 运行时成本、hydration 成本、团队规范失控 |
| 大型团队长期产品 | 类型系统、组件体系、测试和构建约束 | 工具选型频繁摇摆，迁移成本吞掉收益 |
对离开前端多年的工程师来说，动作很简单：别急着把所有新名词补齐。先把声明式 UI、构建步骤、SSR、hydration、RSC 这几件事串起来。理解链条，比背框架名单更值钱。
对正在被工具链折磨的产品型开发者来说，也别急着换栈。
先做一次页面盘点：哪些页面必须重交互，哪些只是展示和提交，哪些真的依赖 SEO 和首屏速度。能从“全站一个重框架”拆成“核心应用重、内容页面轻”，收益往往比追下一个工具更实在。
我更在意接下来两个变量。
一个是默认 JS 预算会不会变小。也就是团队会不会把“少发 JS”变成工程约束，而不只是性能口号。
另一个是服务器组件、岛屿架构、resumability 这些路线，能不能把复杂度藏到框架和基础设施里，而不是继续转嫁给每个业务开发者。
如果藏不住，所谓新架构只是换一批新名词。
前端这二十年，不是从简单走向愚蠢，而是从网页走向软件，再从软件疲劳里重新寻找网页。
主线很清楚：浏览器越强，用户越急，业务越贪，工程就越厚。
“天下熙熙，皆为利来。”放在这里并不违和。复杂度背后有真实收益：更复杂的产品、更顺滑的体验、更安全的重构、更快的协作。
代价也是真的：学习曲线、构建负担、运行时成本，以及开发者对网页本能的遗忘。
那只按钮没有变复杂。
是我们对按钮背后的世界，要求太多了。