手作时代的前端：那个改代码要等五分钟的下午

2008年秋天的一个周六下午，十四岁的林晓蹲在出租屋的旧电脑前，盯着屏幕上那个灰扑扑的个人博客，手指在键盘上悬了十分钟，迟迟不敢敲下保存键。他刚刚把侧边栏的背景色从#333改成了#666——仅仅是一个十六进制颜色的改动——但他知道，这一敲下去，至少得等五分钟。

那台装着Windows XP的台式机配置低得可怜，1GB内存，奔腾4处理器，跑Firefox 3.6都要卡半分钟。更要命的是，他的博客代码全塞在同一个index.html文件里：顶部是<!DOCTYPE html>，接着是满屏的<style>标签，里面混着几十条CSS规则，然后是<body>里的几百行HTML结构，最底部是<script>标签，装着从各处抄来的jQuery插件、统计代码、留言板脚本，还有他自己写的十几段JS逻辑。没有外部文件，没有模块分离，所有东西都像一锅煮糊的粥，搅在一起。

每次修改代码，他都要手动刷新整个页面。Firefox会重新解析所有HTML、重新加载所有CSS、重新执行所有JS，包括那个从网上下载的、他看不懂的jQuery轮播图插件，还有那个会向服务器发送统计请求的CNZZ代码。页面跳转一下，白屏，然后慢慢加载，轮播图重新跑一遍，统计脚本再发一次请求，最后才能看到改完的颜色。如果效果不好，再改，再等。一个下午折腾下来，改了八次颜色，统计脚本向服务器发了八次重复请求，他觉得自己像个傻子。

但更糟的还在后头。那天下午他决定给博客加个“时光轴”功能，展示自己过去写的文章列表。他从网上找了个现成的JS插件，兴冲冲地复制粘贴到<script>标签里，结果一刷新，原本正常的“返回顶部”按钮突然失效了。他查了半小时才发现，那个新插件里也定义了一个叫$的变量，把他之前引入的jQuery的$覆盖了。他盯着屏幕上那几百行挤在一起的JS代码，第一次感到一种无力感：这么多代码搅在一起，连个变量冲突都找不到在哪，更别说加新功能了。

这种无力感在准备把博客上传到免费空间的时候达到了顶峰。他在本地开发的时候，所有资源路径都是相对路径，比如<script src="js/jquery.js"></script>，上传的时候因为目录结构变了，他得手动把所有路径改成绝对路径，或者一个个调整相对层级。有一次他漏改了一个CSS文件的路径，上线后整个页面样式全乱，字体变得巨大，图片全歪了，有个网友在留言板里调侃：“你博客是被黑客攻击了吗？”他躲在被子里，觉得脸烫得能煎鸡蛋。

那时候他还不懂什么是“前端工程化”，不知道什么模块化、构建工具、自动化部署，他只知道：写前端代码真他妈累。

如果把2010年之前的前端开发比作木工活，那简直是最原始的手工时代。没有电锯，没有电钻，没有砂纸机，全靠一把手工锯、一个锤子、一把凿子。你要做一个书架，得先把木头锯成板，用锤子一点点敲出榫卯，再用凿子修整缝隙，整个过程全靠手工，效率极低，稍微不小心就会把木头敲裂，前功尽弃。而那时候的前端开发，就是这样的“手工木工”。

所有的代码都堆在一个文件里，就像把所有木料、工具、螺丝全堆在一个工作台上，找一颗螺丝都得翻半天。没有模块化的概念，所有变量都在全局作用域里“裸奔”，就像把所有的工具都放在同一个工具箱里，没有分隔，用的时候乱翻，很容易拿错。没有构建流程，上线前要手动压缩CSS、合并JS、修改路径，就像手工木工要手动磨光木头、组装零件，每一步都容易出错。没有热更新，改一行代码要刷新整个页面，就像每敲一锤子都要停下来重新量尺寸，效率低得让人绝望。

但正是这种“原始”的状态，孕育了改变的种子。林晓不是唯一一个被这种开发方式折磨的青少年开发者。2005年到2010年间，随着Blogger、WordPress、Typecho等博客平台的兴起，越来越多的年轻人开始拥有自己的个人网站。他们像林晓一样，从网上下载模板，修改HTML和CSS，加一点JS特效，然后上传到免费空间。起初只有几十行代码，后来慢慢加上了相册、留言板、统计代码，代码量从几百行涨到几千行，那个原本简单的index.html文件变得越来越臃肿，像一件穿了几十年的旧衣服，到处是补丁，稍一扯就破。

变量冲突是最常见的问题。那时候还没有AMD、CMD、ES Module这些模块化规范，所有JS代码都共享全局作用域。你引入了一个轮播图插件，它定义了全局变量carousel；我又引入了一个图片放大插件，它也定义了全局变量carousel；结果两个插件打架，轮播图不转了，图片放大也失效了。更糟糕的是，这些错误往往不会直接报错，而是悄无声息地让某个功能“莫名其妙地坏了”，青少年开发者们花几个小时debug，最后发现是某个第三方插件的全局变量被覆盖了，那种挫败感足以让很多人放弃继续学前端。

路径问题则是最容易在上线时踩的坑。本地开发的时候，文件都在同一个目录下，<script src="jquery.js"></script>没问题。但上线的时候，你可能把CSS文件放在css目录下，JS文件放在js目录下，图片放在images目录下，相对路径一变，之前的路径全错了。很多青少年开发者第一次上线时都遇到过“页面样式全乱”的情况，排查了半天才发现是CSS文件路径写错了。那时候还没有webpack这样的工具可以自动处理路径，全靠手动改，一改就是几十上百处，漏一个就会出问题。

还有性能问题。那时候没有代码压缩、代码分割、懒加载这些概念，所有JS、CSS都一股脑塞进页面里。一个简单的个人博客，加载的JS可能就有几百KB，在网速只有几KB/s的拨号时代，打开一个页面要等十几秒。青少年开发者们想优化，但不知道从哪下手，只能把大段大段的JS删掉，结果功能又坏了。

这些坑，每一个林晓都踩过。他曾经为了一个变量冲突，花了三个晚上逐行注释代码，最后定位到一个不起眼的统计脚本；他曾经因为上线时路径错误，被整个班级的同学嘲笑博客“被黑了”；他曾经想给博客加个评论功能，但因为JS代码太多，页面加载太慢，最后放弃了。

但正是这些踩坑的经历，让他开始思考：有没有更省力的办法？

2009年底，林晓在某个技术论坛上看到有人推荐一个叫“YUI Compressor”的工具，说是可以把CSS和JS压缩成更小的文件，减少加载时间。他像发现新大陆一样下载了那个Java写的工具，按照教程把CSS和JS压缩后再上传，页面加载速度果然快了不少。那时候他还不知道，这其实就是前端工程化的雏形——用工具代替手工。

后来他又看到了RequireJS，一个可以实现JS模块化的工具。他试着把自己的JS代码拆成一个个模块，用define()定义，用require()引入，再也不用担心全局变量冲突了。那天晚上他兴奋得睡不着觉，第一次觉得前端开发原来可以这么有序。

但这些工具只是点状的解决方案，没有形成体系。要压缩CSS，得手动跑YUI Compressor；要做模块化，得手动引入RequireJS；要上线，还得手动改路径、手动上传FTP。整个开发流程依然 fragmented，像一堆散在地上的工具，你得自己一个个捡起来用，没有形成流水线。

直到2010年之后，随着Node.js的兴起，前端社区才开始真正系统地思考工程化的问题。Grunt、Gulp这样的任务运行工具出现了，你可以把压缩代码、模块化、自动刷新这些任务配置成一条流水线，保存代码就自动执行。再后来，Webpack横空出世，把模块化、代码打包、资源处理、热更新这些功能全部整合在一起，前端工程化终于从“手工木工”时代进入了“电动工具”时代。

但那是后话了。在2008年那个秋天的下午，林晓还不知道这些。他只知道，改一个颜色要等五分钟的日子，真的过够了。他关掉Firefox，打开记事本，开始把那个几千行的index.html文件里的CSS代码剪切出来，放进一个单独的style.css文件里。这是他的第一次重构，笨拙，缓慢，但他觉得，这一步必须走。

窗外的梧桐叶飘落，出租屋里的旧电脑风扇嗡嗡响。他不知道，自己正站在一个巨大变革的起点上。那些后来被称为“构建工具”的东西，那些后来改变整个前端行业的工具链，此刻还没有诞生。但那些因为手工开发而滋生的痛苦、那些踩坑后的思考、那些对更高效工作流的渴望，正是推动这一切变革的最原始的动力。

就像所有伟大的手工艺革命都源于工匠对低效的不满，前端工程化的萌芽，也源于无数个像林晓一样的青少年开发者，在无数个改代码等五分钟的下午，在心里默默呐喊：“一定还有更好的办法。”

这种呐喊，最终汇聚成了改变行业的力量。而我们要讲的，正是这股力量如何从无到有，如何从简陋到完善，如何从解决一个少年博客的小问题，演变成支撑整个现代Web开发的庞大体系。从那个手动剪切CSS代码的下午开始，前端开发的手工时代，已经悄然走到了尽头。

---

如果你也在2008年玩过博客，你大概记得那种痛苦：改一行代码，刷新等半天；加个功能，变量冲突；上线一次，样式全乱。那时候的前端开发，就像没有电动工具的木工，全靠一双手，效率低得让人绝望。但正是这种“原始”的状态，逼着开发者们去寻找更高效的解决方案，最终催生了Webpack、Vite这些改变行业的构建工具。

接下来，我们就回到那个“手作时代”的前端，看看在没有工程化的年代，开发者们到底经历了什么。我们会从林晓的博客讲起，看看一个简单的个人网站是如何暴露出前端开发的诸多痛点，又是如何一步步推动工程化需求的产生。我们会具体看看：

• 那个年代的前端代码到底有多“乱”：所有代码堆在一个文件里是什么体验？
• 变量冲突是怎么发生的：为什么引入一个jQuery插件会导致其他功能失效？
• 上线时的“路径噩梦”：为什么改个路径要改几十上百处？
• 性能优化的“无米之炊”：没有工具的时候，怎么压缩代码、优化加载？

这些看似琐碎的踩坑经历，其实正是前端工程化诞生的土壤。理解了这些痛点，你才能真正明白Webpack、Vite这些工具为什么会出现，它们到底解决了什么问题。

准备好了吗？让我们回到2008年，回到那个改代码要等五分钟的下午。

2008年深秋的那个下午，林晓把index.html里几百行<style>标签里的代码剪切出来，粘贴到新建的style.css文件里，又在HTML头部加了一行<link rel="stylesheet" href="style.css">。做完这一步，他靠在椅背上松了口气，觉得好像解决了一个大问题。但他不知道，这只是他踩坑生涯的开始，而接下来遇到的每一个问题，都会成为后来前端工程化发展道路上的一个个注脚。

那时候的他，和所有2005年到2010年间的青少年个人站长一样，用的是一套“原始”的开发工具链：编辑器是破解版的Dreamweaver 8，或者免费的Notepad++，连语法高亮都要手动开；浏览器是Firefox 3.6和IE6并排摆着，改完代码先看Firefox，再切到IE6看兼容性，IE6一卡就是半分钟，他经常等得想砸鼠标；上传工具是FlashFXP，要手动一个个选文件上传，传错了还要删了重传；代码备份全靠U盘，文件夹里按日期命名着“博客备份20081001”“博客备份20081015”，后来那个128MB的U盘丢了，他半年的代码全没了，蹲在教室门口哭了十分钟。

他把拆出来的CSS文件保存，刷新页面，样式居然正常显示。那天他兴奋得吃了两大碗泡面，觉得拆分文件是个天才的发明。但没过两天，新的问题就来了：他的JS代码还是堆在HTML底部的<script>标签里，几百行代码挤在一起，变量冲突越来越频繁。之前只是两个插件抢$变量，后来连他自己写的变量都开始打架——他给轮播图写的变量叫currentIndex，后来加了一个文章列表的排序功能，也用了currentIndex，结果两个功能同时运行的时候，轮播图跳着跳着就跳到了第一张，排序也排得乱七八糟。

那时候他还不知道什么是“作用域”，什么是“全局变量污染”，他只知道自己的代码“闹鬼”了。他试着把JS代码也拆成单独的文件，比如把轮播图的代码放到carousel.js，把排序代码放到sort.js，然后在HTML里分别引入： ```html <script src="js/sort.js"></script> <script src="js/carousel.js"></script> <script src="js/jquery.js"></script> ``` 结果一刷新，控制台（那时候他还不知道有控制台，是后来装了Firebug才发现的）里报了一堆错，第一行就是“jQuery is not defined”。他盯着代码看了半小时，才搞明白：JS是按顺序执行的，carousel.js里用了jQuery的$，但是jQuery的脚本在它后面加载，所以执行到carousel.js的时候，jQuery还没被加载，自然就报错。他赶紧把顺序调过来： ```html <script src="js/jquery.js"></script> <script src="js/carousel.js"></script> <script src="js/sort.js"></script> ``` 果然不报错了，但他很快发现新的问题：后来他加了一个图片灯箱插件lightbox.js，这个插件也依赖jQuery，而且依赖jQuery的1.7以上版本，但他之前用的jQuery是1.3.2的旧版本，一引入lightbox.js，轮播图又坏了。他跑到jQuery官网下载了1.7版本，替换掉旧的，结果发现之前写的某个旧的插件又不兼容1.7了，又报错。他蹲在电脑前，看着满屏的红色报错，第一次觉得JS代码就像一堆互相缠绕的毛线，拉一下这里，那里就紧了。

这种依赖冲突的问题，在2010年之前的个人开发者圈子里非常普遍。那时候还没有npm、yarn这样的包管理工具，要引入一个JS插件，得先跑到插件的官网，下载压缩包，解压，然后把js文件复制到自己的项目目录里，再在HTML里手动引入。要是插件有依赖其他库，还得自己去找依赖的库，手动下载，手动引入，版本不兼容就得自己改插件代码，改得乱七八糟也不敢删，生怕删了一行就报错。林晓的js文件夹里塞了二十多个JS文件，有jQuery、有轮播图插件、有灯箱插件、有统计代码、有留言板脚本，还有他自己写的十几个功能文件，每个文件之间互相依赖，顺序错一点都不行，加一个新功能之前，他得先花半小时理清楚各个文件的依赖顺序，生怕把哪个功能搞坏。

如果说变量冲突和依赖问题还能靠手动调整顺序解决，那上线前的路径问题就是真正的噩梦。林晓本地开发的时候，所有文件都在同一个目录下，index.html、style.css、js文件夹、images文件夹都在同一个层级，所以路径写起来很简单：<script src="js/jquery.js"></script>，<img src="images/avatar.jpg">。但免费空间的上传规则不一样，有的要求把HTML文件放在根目录，CSS放在css文件夹，JS放在js文件夹，图片放在images文件夹，和本地的结构一样还好，要是免费空间的结构不一样，比如要求把所有静态文件都放在static文件夹下，那所有的相对路径全得改。

他第一次上线的时候，就踩了这个坑。免费空间要求所有静态文件放在static目录下，他本地是css/style.css，上线就要改成static/css/style.css，他的博客里有三十多个CSS引用、二十多个JS引用、五十多张图片引用，加起来一百多处路径，他一个个手动改，改了整整两个小时，改到最后眼都花了，漏改了一个CSS文件的路径，结果上线后整个页面样式全乱，标题字体大得像楼牌，图片全部错位，侧边栏跑到了页面底部。那天他刚好在班级里宣传了自己的博客，很多同学都去访问，结果看到乱成一团的页面，有人在留言板里调侃：“你博客是不是被黑客挂马了？”他当时脸烫得能煎鸡蛋，赶紧关掉页面，花了一个小时才找到漏改的那行路径。

后来他学聪明了，上线前会先把所有的路径列在一张纸上，一个个打勾，但还是会漏。有一次他漏改了一个JS文件的路径，结果页面上的轮播图不转，灯箱点不开，评论也发不了，他以为是自己代码写错了，查了整整一个下午，最后才发现是路径错了。那天他发誓再也不手动改路径了，但他不知道，直到Webpack这样的工具出现，这个问题才被真正解决。

除了变量冲突、依赖问题、路径问题，那时候的前端开发还有一个最大的痛点：效率极低。林晓的台式机配置是奔腾4处理器，1GB内存，80GB的机械硬盘，跑Firefox 3.6要等半分钟，打开一个网页要等十几秒。每次改完代码，他都要手动刷新整个页面，浏览器要重新解析所有HTML、重新加载所有CSS、重新执行所有JS，包括那个从网上下载的、他看不懂的jQuery轮播图插件，还有那个会向服务器发送统计请求的CNZZ代码。页面先白屏，然后慢慢加载，轮播图重新跑一遍，统计脚本再发一次请求，最后才能看到改完的效果。如果效果不好，再改，再等。

他印象最深的一次，是改侧边栏的背景色。他一开始选的是#333，觉得太深，改成#666，觉得太浅，改成#555，觉得还是不够好，前前后后改了八次，每次刷新等三分钟，一个下午就没了，连午饭都没吃，他妈喊他吃饭他还发火，说“正忙着呢”。他妈端着一碗排骨汤站在他房间门口，说“忙什么忙，改个颜色要改一下午，你是在画画吗？”他当时没说话，等他妈走了，他盯着屏幕上的#555，突然觉得特别委屈：我只是想改个颜色，为什么要等这么久？

那时候他还不知道什么是“热更新”，什么是“增量编译”，所有工具都只能全量处理代码。要压缩CSS，他得手动把style.css里的所有换行、空格、注释全删掉，或者用论坛上推荐的YUI Compressor——一个雅虎公司开源的Java工具，要压缩CSS得先装Java环境，他装Java环境就装了两个小时，还装错了版本，跑命令的时候一直报错，最后照着论坛上的教程一步步敲，才终于把CSS压缩成了style.min.css，文件大小从12KB降到了5KB，他开心得像个孩子，但后来他发现手动压缩太容易出错了：有一次他压缩CSS的时候，不小心删掉了一个花括号后面的分号，整个CSS全乱，他又花了一个小时找哪里错了，最后发现是删掉了一个分号，气得他把键盘砸了一下，手都砸红了。

如果要给2010年之前的手作时代前端开发画一张流程图，那一定是这样的：

```mermaid graph TD A[写HTML/CSS/JS] --> B[手动刷新页面测试] B --> C{效果符合预期?} C -->|否| A C -->|是| D[手动压缩CSS/JS] D --> E[手动修改所有资源路径] E --> F[手动用FTP上传所有文件] F --> G{上线正常?} G -->|否| A G -->|是| H[完成] ```

每一步都是手动操作，每一步都容易出错，整个流程没有任何自动化，全靠开发者的记忆和耐心。林晓曾经算过，他每次上线要花至少两个小时，其中四十分钟用来改路径，三十分钟用来压缩代码，四十分钟用来上传文件，剩下十分钟用来祈祷不要出错。但大部分时候，他还是会出错，要么是路径漏改了，要么是压缩的时候删错了字符