蛮荒时代：没有工程化的前端

2005年的北京，中关村还飘着刚拆完的尘土味道，西二旗地铁站挤满了背着双肩包的年轻人。小明——一个刚转行做“网页制作”的23岁青年，正蹲在租住的地下室里，对着15英寸的CRT显示器调试一个下拉菜单。屏幕右下角的IE6图标闪烁着，页面里的JavaScript错误提示像幽灵一样反复出现：“对象不支持此属性或方法”。他抓了抓三天没洗的头发，瞥了一眼桌上散落的《JavaScript高级程序设计》（那还是本影印版），又看了看墙上手写的排期表：“电商首页——周三上线”。空气里弥漫着泡面和焦虑混合的气息。这，就是2005年中国互联网前端开发的缩影：一个没有工程化、没有模块化、没有自动化，全靠双手和意志力在原始丛林里开路的“蛮荒时代”。

一、2005：互联网的“拓荒时代”与“切图仔”的生存法则

要理解前端的“蛮荒”，必须先回到那个时代的互联网本身。2005年，全球网民总数刚刚突破10亿，中国网民约1.1亿，宽带普及率不足15%。Web 2.0的概念正被炒得火热，但用户体验远非今日标准。网页以表格（Table）布局为主流，CSS2.1尚未完全定稿，浏览器兼容性是一场没有规则的战争：IE6占据绝对主导（市场份额一度超过90%），Firefox 1.0刚发布，Safari和Chrome还远未诞生。Ajax技术因Google Maps和Gmail而备受瞩目，但实现它需要手动处理XMLHttpRequest对象的浏览器差异，没有统一的库。

在这样的技术荒漠中，“前端开发”作为一个独立岗位几乎不存在。它通常是网页设计师的延伸，或后端工程师的“附属工作”。从业者被戏称为“切图仔”——核心技能是用Photoshop将设计稿切成HTML页面，然后“随便”加些动态效果。代码组织方式近乎原始：一个项目通常由一个或多个`.html`文件，以及若干`.js`、`.css`文件直接构成。没有“项目”的概念，只有“文件”。依赖关系？靠程序员脑子记。版本控制？多数小团队甚至不用SVN，直接用U盘或邮件传文件。小明所在的“迅捷科技”正是典型：一个15人的创业公司，后端用Java+Struts，数据库是Oracle，而前端——就是小明和他师傅“老王”两个人。

老王是2003年入行的“老炮”，信奉“能跑就行”的哲学。他教小明的第一课是：“记住，script标签放最后，不然页面会卡住。” 第二课是：“变量名别太通用，比如`i`、`temp`，小心被人覆盖。” 第三课是：“改完代码，自己多点点，别信浏览器。” 这些土法炼钢的经验，是那个时代前端工程师的“生存法则”，背后是缺乏工具支撑的血泪教训。

二、小明的典型一天：在“脚本顺序”与“全局变量”的钢丝上行走

让我们跟随小明，经历一个“正常”的工作日。

早晨9:00：产品经理递来一张新需求：“首页轮播图增加‘自动播放’和‘左右切换按钮’。” 设计稿昨天已交付。小明打开`index.html`，看到底部已经堆积了七八个`<script>`标签： ```html <script src="js/prototype.js"></script> <script src="js/effects.js"></script> <script src="js/validation.js"></script> <script src="js/cart.js"></script> <script src="js/main.js"></script> <script src="js/header.js"></script> <script src="js/footer.js"></script> <script src="js/slider.js"></script> <!-- 新文件，小明刚加 --> ``` 老王交代：“`slider.js`依赖`effects.js`里的动画函数，一定要放在它后面！” 小明小心翼翼地把新标签插在`effects.js`之后、`validation.js`之前。但`validation.js`又依赖`prototype.js`，而`cart.js`和`main.js`有复杂的交互……这种“依赖链”完全靠人工维护，像在雷区排雷。某次后端工程师修改了`common.js`（一个被所有页面引用的工具库），因未通知前端，导致全站搜索功能瘫痪两小时——这就是著名的“脚本顺序地狱”。

上午10:30：开始写`slider.js`。没有模块系统，所有变量、函数都默认声明在全局作用域。小明想定义一个轮播图实例： ```javascript var currentIndex = 0; var autoPlayTimer = null; function startAutoPlay() { /* ... */ } function switchTo(index) { /* ... */ } ``` 但`validation.js`里也有一个`currentIndex`用于表单分步验证！当两个文件同时加载，后加载的会覆盖先加载的。小明只能拼命想独特的名字：`slider_currentIndex`，`validation_currentIndex`……很快，全局命名空间像被不同家族占用的公共走廊，贴满“王家暂住”“李家存放”的纸条，混乱不堪。这就是“全局变量污染”——它让代码耦合如一团乱麻，任何修改都可能引发意想不到的“幽灵bug”。

下午2:00：产品经理追加：“轮播图切换时，要异步加载对应商品的推荐数据。” 这意味着在`switchTo`函数里发起Ajax请求。2005年，没有Promise，没有async/await，只有回调函数。小明的代码逐渐变成“金字塔之死”： ```javascript function switchTo(index) { currentIndex = index; updateUI(); // 异步加载商品推荐 new Ajax.Request('/api/recommend', { method: 'get', parameters: {id: productIds[index]}, onSuccess: function(response) { var data = response.responseJSON; // 处理数据... renderRecommend(data); // 又需要异步加载广告？ new Ajax.Request('/api/ad', { method: 'get', parameters: {slot: 'home_slider'}, onSuccess: function(adResponse) { renderAd(adResponse); // 再嵌套一个？... }, onFailure: function() { alert('广告加载失败'); } }); }, onFailure: function() { alert('推荐加载失败'); } }); } ``` 三层嵌套已让代码缩进如悬崖，逻辑难以追踪。若再增加一层，将是“回调地狱”的噩梦：错误处理分散、代码复用困难、退出条件复杂。小明每次修改这里，都像在迷宫里拆弹。

下午4:00：测试发现，在Firefox下轮播图动画卡顿。老王说：“IE的`filter`属性Firefox不支持，得写浏览器判断。” 于是代码里又插入大量`if (navigator.userAgent.indexOf('MSIE') > -1)`。这种“浏览器嗅探”代码像牛皮癣一样贴满每个功能模块，使文件体积臃肿，逻辑交错。

傍晚6:30：准备提测版本。上线流程堪称“手工活化石”：小明必须手动将`index.html`、`css/`目录、`js/`目录、`images/`目录复制到一个临时文件夹。然后，用记事本打开每个JS文件，手动复制粘贴，合并成一个`all.min.js`（为了减少HTTP请求，这是当时“优化”的标配）。顺序必须严格：工具库→基础组件→业务逻辑。一次，他忘记把`slider.js`合并进去，测试环境正常（因为开发时单独引用），生产环境轮播图直接静默失效。还有一次，合并时漏了一行`});`，导致整个站点JavaScript解析错误，白屏。这种“手动合并文件”的步骤，是每个前端工程师的梦魇，它极易出错，且无法回滚。版本回退？只能靠备份的整个文件夹命名“backup_20051012”，像考古一样恢复。

晚上9:00：终于部署完成。小明揉着酸涩的眼睛，看着屏幕上轮播图顺利切换，长舒一口气。但他知道，明天可能因为一个全局变量被覆盖，或脚本顺序错误，一切重来。这种“救火式开发”消耗着团队的精力与热情。项目初期简单页面尚可驾驭，但随着功能膨胀——用户中心、购物车、支付流程、后台管理——数十个JS文件、上百个全局变量、错综复杂的依赖，代码库变成了谁也不敢碰的“黑箱”。任何微小改动都需全链路回归测试，而前端测试主要靠“人手点点”。这就是没有工程化的代价：开发效率随项目规模增长而指数级下降，维护成本高到令人窒息。

三、三大“原罪”：全局变量污染、回调地狱与手动合并的深度剖析

小明的日常，折射出蛮荒时代的三大技术“原罪”。它们并非独立存在，而是相互交织，共同将前端开发拖入泥潭。

1. 全局变量污染：共享的“公共黑板”与不可预测的覆盖

在JavaScript早期，语言设计本身缺乏原生模块封装能力（IIFE即时执行函数是当时常用的土办法）。所有未用`var`声明的变量自动成为全局属性，即便用`var`，在函数外声明也是全局。想象一个办公室只有一块公共黑板（`window`对象），每个员工（每个JS文件）都可以写任何内容，且不能擦除别人的笔记。当A部门写下“今日会议：10点”，B部门过来直接改成“今日会议：11点”，A的同事将完全迷失。代码中，一个库定义`var utils = {...}`，另一个库也定义`var utils = {...}`，后者无声覆盖前者，导致依赖前者的功能全部失效。这种污染是隐形的、跨文件的、难以追踪的。调试时，你永远不知道某个变量在哪个时刻被谁修改了。唯一“解决方案”是命名空间约定（如`MyApp.utils`），但这依赖开发者自觉，且无法解决深层嵌套对象的覆盖问题。它从根本上破坏了代码的封装性与可预测性。

2. 回调地狱：异步编程的“金字塔陷阱”

Web的异步本质（网络请求、用户事件）在早期没有优雅的抽象。回调函数是唯一工具，但多个异步操作存在依赖时，代码会自然向右深缩，形成视觉和逻辑上的“地狱”。上述轮播图例子中，加载商品推荐后又要加载广告，广告加载完可能还要统计曝光……每一层嵌套都引入新的作用域，错误处理必须重复，退出逻辑（如用户中途切换轮播图）难以插入。更可怕的是，错误处理与成功处理分离（`onSuccess`/`onFailure`），导致代码路径分散。当嵌套超过三层，开发者需 mentally 跟踪每个回调的触发时机与数据状态，如同走钢丝。这种模式不仅丑陋，更严重损害代码的可读性、可维护性和错误恢复能力。一个常见的反模式是“回调金字塔”中混杂业务逻辑，使得任何需求变更都需重构整个嵌套结构。

3. 手动合并文件：上线前的“致命手工课”

HTTP/1.1协议下，每个资源请求都有开销，合并文件是性能优化的必选项。但手动合并是极端脆弱的流程：

• **顺序依赖**：文件合并顺序必须严格遵循依赖图。A依赖B，B依赖C，则顺序为C→B→A。但依赖关系常是网状的（如A和B互相引用），手动排序几乎不可能完美。
• **人为错误**：遗忘文件、重复包含、顺序颠倒、复制时丢行……这些错误在开发环境难以发现（因单独引用），只在生产环境爆发，定位困难。
• **无法增量**：每次上线需全量合并，即使只改一行代码。团队协作时，两人修改不同文件，合并冲突在`all.min.js`里无法直观解决，只能重新手动整合。
• **破坏调试**：合并后代码压缩（常手动用工具如`JSMin`），但无source map，线上错误堆栈指向压缩后的匿名行号，调试如同盲人摸象。

这三大“原罪”像三根绳索，将前端开发捆绑在低效、高风险、高焦虑的状态。项目初期，绳索松散，尚可行动；项目膨胀，绳索收紧，直至窒息。小明的团队并非特例——2005年前后的中国互联网，从门户到电商，无数项目都在重复同样的挣扎。一些早期技术社区（如JavaScript.cn）的帖子里，充斥着“如何避免全局变量冲突”“多个JS文件加载顺序问题”等讨论，那是整个行业在蛮荒中的集体呻吟。

四、一个灾难性夜晚：当所有问题同时爆发

为了具象化这种混乱，让我们聚焦小明项目一次真实的“生产事故”。

那是一个周四晚上，电商“双十一”预热活动上线。小明根据需求，新增了一个“秒杀倒计时”模块：

• `countdown.js`：计算剩余时间，每秒更新DOM。
• `seckill.js`：倒计时结束时，发起Ajax请求抢购。
• 两者都需要一个`formatTime`函数，小明图快，在`countdown.js`里定义了一个，又在`seckill.js`里重新定义了一个（因两人并行开发，未沟通）。
• `seckill.js`依赖`jQuery`（刚引入，放在`prototype.js`之后），但`countdown.js`被错误地放在了`jQuery`之前。
• 上线前，小明合并文件：先合并了旧有的`all.js`，然后**手动**把新文件内容粘贴到最后，忘记检查顺序。

结果： 1. 倒计时显示NaN（因`formatTime`被覆盖，且`seckill.js`中定义的版本依赖未加载的`jQuery`对象）。 2. 秒杀开始时，Ajax请求因`$`未定义而失败，用户点击无反应。 3. 更隐蔽的是，`countdown.js`里有个全局变量`timerId`用于`clearInterval`，而`seckill.js`也有同名变量，导致倒计时无法停止，CPU占用飙升。 4. 小明紧急回滚到上一版备份，但备份中`all.js`已包含前一天的其他修改，回滚后“购物车数量显示”又出错了——一次上线，引发连环故障。

运维电话打爆，产品经理在群里咆哮，运营同事抱怨用户投诉。小明和老王熬到凌晨三点，通过逐行对比备份文件，才定位到是全局变量冲突和脚本顺序错误。修复过程：先改文件引用顺序，再给变量加前缀，重新合并，测试，再上线。一次简单的功能发布，耗费了8人时的排查与修复成本。这绝非孤例。据2006年一份非正式的前端开发者调查（基于技术论坛抽样），约65%的受访者表示“每周至少遇到一次因脚本顺序或全局冲突导致的线上问题”，而“手动合并文件”被列为“最恐惧的部署步骤”。这种高故障率不仅影响用户体验，更严重消耗团队士气与信任——工程师开始害怕修改代码，产品经理对前端迭代速度失去信心，企业为“快速试错”的互联网精神套上了枷锁。

五、工具荒漠：我们曾如何“徒手”工作

回顾那个时代，并非全无工具，但它们是碎片化的、辅助性的，无法构成“工程体系”。

• **库/框架**：2005年，Prototype.js（2005年发布）和早期jQuery（2006年发布）正开始流行，它们主要解决DOM操作和浏览器兼容，但**不提供模块或构建能力**。使用它们，只是换了一种方式写全局代码。
• **版本控制**：SVN是主流，但前端二进制文件（如图片）合并困难，且缺乏针对前端文件的差异比较工具。合并冲突时，常看到“<<<<<<< .mine”标记散落在JS代码中，需人工 reconciliation。
• **调试**：Firebug（2006年发布）尚未诞生或初期。IE的“开发人员工具”要到IE8。调试主要靠`alert()`大法和`document.write`，效率极低。压缩后的代码几乎无法调试。
• **包管理**：npm（2010年发布）远未出现。依赖一个库，需手动下载.js文件放入项目，更新时再手动覆盖。
• **任务运行**：没有Grunt、Gulp、Webpack。压缩用`JSMin`命令行，需手动写脚本；CSS雪碧图用在线工具生成，再手动替换背景坐标。

这些工具如同石器时代的石斧——有用，但需要自己打造、磨利，且每人打造的形态不一。它们没有形成“工作流”，更谈不上“自动化”。前端工程师的日常，是在无数个重复、易错、低价值的操作中消耗时间。小明曾计算：一个中型功能开发，编码仅占30%，其余70%是：调试跨浏览器问题（20%）、手动合并与测试（30%）、处理因代码混乱导致的回归bug（20%）。这70%，正是工程化旨在夺回的时间。

六、为什么我们忍受了这么久？——蛮荒时代的“合理性”

面对如此低效，为何这种状态持续了数年？深层原因有三：

其一，前端角色边缘化。在“后端驱动”的Web架构中，前端被视为“界面装饰”，复杂度低、变更频率低。业务逻辑、数据存储、安全认证皆在后端，前端只需“展示”。企业投入资源优先解决后端性能、扩展性，前端“能跑就行”成为默认标准。工程化是“锦上添花”，而非“生存必需”。

其二，技术认知局限。早期JavaScript被视为“玩具语言”，缺乏严谨工程实践的文化。模块化、依赖管理、构建流水线，这些在Java、C#领域成熟的概念，很少被移植到前端。社区普遍缺乏“软件工程”思维，更关注“技巧”与“ hack”。

其三，生态未成熟。浏览器标准滞后（ES6模块2015年才定稿），工具链缺乏统一范式。没有npm，就没有包依赖管理；没有Source Map，就没有调试信心；没有Babel，就没有语法前瞻性。一切条件未备。

然而，互联网的爆发式增长最终撕开了这张遮羞布。2006年后，Ajax应用（如Google Docs）展示出富客户端的潜力；2007年iPhone诞生，移动Web兴起；2008年GitHub上线，开源协作加速。前端代码量从几百行飙升到数万行，交互从表单提交变为单页应用（SPA）。蛮荒时代的工具与模式，在复杂度面前彻底崩塌。小明的故事，正是这场崩塌前的宁静——风暴已在路上。

七、伏笔：变革的星火从何燃起？

在混乱中，已有先行者开始摸索出路。2005-2009年，几个关键思想与工具悄然萌芽，为后续工程化革命埋下伏笔：

• **模块模式（Module Pattern）**：利用闭包模拟