Web程序设计：从一张空白HTML说起

打开记事本，序设敲下<h1>Hello</h1>，序设保存为index.html，序设双击。序设浏览器弹出一行黑字。序设整个过程不到十秒。序设这就是序设Web程序设计最原始的模样——没有编译器，没有构建工具，序设没有依赖注入。序设一个文本文件，序设一个渲染引擎，序设完事。序设

但事情很快会变复杂。序设你加了CSS，序设页面好看了。序设加了JavaScript，按钮能点了。然后你发现每次改代码都要手动刷新浏览器，于是装了Live Server。再然后你发现DOM操作写起来像搬砖，于是引入了jQuery。再再然后你发现jQuery也救不了你，于是上了React。回头看，你已经站在一个node_modules体积超过node_modules黑洞临界值的项目里，而最初那行<h1>早就不见了。

这不是讽刺。这是Web程序设计的真实路径。它的核心矛盾一直没变过：浏览器只认识三样东西——HTML、CSS、JavaScript。所有框架、预处理器、打包工具，最终都要翻译回这三样。你写的每一行TypeScript，每一个JSX标签，每一段Sass嵌套，最后都得变成浏览器能啃的骨头。

理解这一点，很多困惑就通了。为什么useEffect的依赖数组让人抓狂？因为它试图在声明式UI里模拟命令式的生命周期。为什么CSS-in-JS有性能争议？因为它在运行时往<style>标签里塞字符串，而浏览器本来可以直接解析静态CSS文件。为什么SSR、CSR、ISR这些缩写满天飞？因为大家在想尽办法平衡首屏速度和交互能力——这两件事在Web上天生打架。

举个具体的例子。假设你要做一个待办列表。原生写法大概三十行：一个<ul>，一个<input>，一个addEventListener，一个createElement，一个appendChild。用React写，你需要useState、map渲染、onChange处理、key属性，代码量翻倍。但如果你要做一百个互相联动的组件，原生写法会变成意大利面条，而React的组件树还能看。框架不是让你写得更少，是让你在规模变大时死得慢一点。

另一个常被忽略的点：HTTP是无状态的。你登录了，刷新页面，服务器不认识你了。于是有了Cookie、Session、Token、JWT。这些东西不是Web程序设计本身，但你不懂它们就做不了任何真实项目。前端路由也是同理——URL变了但不请求服务器，靠的是history.pushState和浏览器的popstate事件。react-router也好，vue-router也好，底层都是这个。

我见过不少初学者卡在“学不完”的焦虑里。今天Vue明天React，后天又出了SolidJS和Svelte。其实换个角度：Web程序设计的本质是管理三件事——状态、视图、副作用。状态是数据，视图是DOM，副作用是网络请求、定时器、本地存储。任何框架都在回答同一个问题：状态变了，怎么最高效地更新视图，同时把副作用管好。React用虚拟DOM和Hooks，Vue用响应式代理和组合式API，Svelte编译时就把更新逻辑写死了。路子不同，目标一样。

所以别被工具链吓住。打开开发者工具，看看Network面板里每个请求的Header和Response。写一个不带任何库的fetch调用，把数据渲染到页面上。手动改一下DOM，感受一下浏览器有多快。这些基本功不会过时。框架会换，npm包会烂，但HTTP协议、DOM API、事件循环——这些东西十年后大概率还在。

最后说一句实在的：Web程序设计不是背API。它是理解约束，然后在约束里找到最不烂的解法。浏览器是个奇怪的环境，它同时要跑广告、跑银行、跑游戏、跑文档。你写的代码只是其中一小块。知道自己在哪一层，比知道多少语法重要得多。