从 jQuery 到模块化：一次前端工程意识的转变

wuwenzen@outlook.com (wuwj) — Fri, 20 Dec 2019 00:00:00 +0000

背景

在较早阶段的前端开发中，常见技术栈以 jQuery + 传统页面结构 为主。
这种模式在页面数量有限、业务逻辑简单时，具备实现成本低、交付速度快的优势。

但随着功能逐步增多、页面之间产生联动，代码结构问题开始显现，对可维护性提出了更高要求。

传统写法暴露的问题

1. 全局作用域污染

var list = [];
function init() {}
function render() {}

常见问题包括：

变量与函数暴露在全局作用域
多页面脚本容易互相覆盖
问题定位与调试成本逐渐升高

2. 文件职责混乱

在缺乏结构约束的情况下：

单个 JS 文件体积不断膨胀
DOM 操作、业务逻辑、接口请求混杂
修改局部逻辑时容易产生连锁影响

3. 代码复用能力弱

相似功能在不同页面中往往通过复制实现：

复制后再做细微修改
长期来看难以统一维护
Bug 修复成本被成倍放大

引入模块化思路

为缓解上述问题，开始尝试在不依赖复杂工具链的前提下，引入基础的模块化设计思想。

1. 按职责拆分代码结构

js/
├── api.js
├── render.js
├── event.js
└── main.js

通过人为约定实现基础分层：

接口请求集中管理
渲染逻辑独立拆分
事件绑定避免分散在各处

即使不依赖构建工具，也能显著提升代码可读性。

2. 使用 IIFE 隔离作用域

(function () {
  var state = {};
  function init() {}
  window.pageInit = init;
})();

这种方式在早期用于：

JavaScript 模块化那些事：从 IIFE 到 ES Modules

wuwenzen@outlook.com (wuwj) — Sun, 10 Mar 2019 00:00:00 +0000

最早写前端的时候，经常是一个 index.html 里塞一大坨 <script>，变量到处飞，函数名一改项目全崩。后来慢慢开始接触各种模块化方案，从 IIFE、AMD、CommonJS 一路走到 ES Modules，心态也经历了从凑合能用到必须有规范。

这篇就当是给自己的一个小总结：为什么需要模块化、几种常见写法的区别、现在应该怎么写。

为什么要模块化？

几个非常现实的问题：

全局变量名冲突：不同文件里不小心定义了同名变量/函数。
依赖关系混乱：这个文件依赖谁？要先引哪个 <script>？
代码难以拆分复用：逻辑越写越大，一改就牵一大片。
测试困难：无法只「拿出一小块」单独测试。

所以模块化要解决的就是：

把代码按职责拆成「小块」 + 明确每块对外暴露什么 + 明确依赖关系。

第一阶段：IIFE 模式（自执行函数）

当时 jQuery 时代最常见的一种写法，就是用自执行函数「造一个自己的小世界」。

(function () {
  const API_URL = '/api/todos';

  function fetchTodos() {
    return fetch(API_URL).then(res => res.json());
  }

  function renderTodos(list) {
    // 渲染逻辑...
  }

  window.todoApp = {
    init() {
      fetchTodos().then(renderTodos);
    },
  };
})();

特点：

用 IIFE 隔离出一个作用域，避免变量污染全局。
需要暴露给外面的东西挂在 window.todoApp 上。
所有代码其实还是在一个文件里，没有真正意义上的「依赖管理」。

适合：小项目 / 简单封装。
不适合：多页面、多模块的大型项目。

第二阶段：AMD / RequireJS

再往后，就出现了 AMD（Asynchronous Module Definition），代表是 RequireJS。

JavaScript on Saiga