# frontend-modularization

**Repository Path**: kayanchan/frontend-modularization

## Basic Information

- **Project Name**: frontend-modularization
- **Description**: 前端模块化的发展进程
- **Primary Language**: JavaScript
- **License**: MIT
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2025-09-26
- **Last Updated**: 2025-09-26

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 前端模块化的发展进程


| **阶段** | **方案** | **语法** | **核心思想** | **适用场景/问题** |
| --- | --- | --- | --- | --- |
| 1. 原始时代 | 全局函数/命名空间 |  | 简单堆砌 | 小型脚本，存在全局污染 |
| 2. 雏形时代 | IIFE |  | 作用域隔离，闭包 | 中小型项目，依赖管理仍不便 |
| 3. 规范化时代 | **CommonJS** | `require`, `module.exports` | 同步加载 | **Node.js 服务器端** |
|  | **AMD (RequireJS)** | `define(['a', 'b'], function(a, b) { ... })` 
`require(['a'], function(a) {…}` | 异步加载，依赖前置 | **浏览器端**，但语法复杂 |
|  | **CMD (Sea.js)** | `define(function(require) { var a = require('a'); ... })` | 异步加载，依赖就近 | 浏览器端+服务器端，与 AMD 有理念之争 |
| 4. 原生时代 | **ES6 Modules (ESM)** | `import`,`export` ,`import()` | 静态编译、`import()`动态 | 浏览器/Node.js 通用，未来标准 |
| 5. 构建时代 | **Webpack/Rollup/Vite** |  | 打包、优化、转换 | 现代前端工程化，解决性能、兼容性、资源管理 |

# 阶段六：构建工具时代 - `Bundler`

虽然浏览器已经支持 `ESM`，但在生产环境中，我们仍然很少直接使用原生 ESM，而是使用构建工具进行打包。

- 为什么需要打包
    1. 性能优化：将成百上千个小模块打包成少数几个文件，减少 HTTP 请求数
    2. 编译转换：使用 `Babel` 将新的 JS 语法（如 `ESM`）转换为兼容性更好的 `ES5`语法
    3. Tree Shaking：剔除未被使用的代码，减小打包体积
    4. 处理非 JS 资源：可以引入 `CSS`、图片、字体等资源
- 主流工具：
    - Webpack：功能强大、生态完善，是目前最主流的打包工具
    - Rollup：尤其适合库的打包，利用 `ESM` 的静态分析能力，打包结果更简洁
    - Vite：基于 `ESM` 的下一代前端构建工具，开发环境下利用浏览器原生 `ESM` 提供极速的热更新，生产环境用 `Rollup` 打包。发展迅猛
    - Parcel：零配置的打包工具，开箱即用

# **阶段五：原生时代 - `ES6 Modules (ESM)`**

- 背景：`ESM`的出现标志着前端模块化终于从“社区规范”时代进入了“语言标准”时代。目前所有现代浏览器和 `Node.js` 都已原生支持 `ES6` 模块。它是目前和未来的绝对主流。
- 定义：`ESM` 是 `ECMAScript 2015 (ES6)` 标准中引入的模块系统。它旨在为 `JavaScript` 创建一种统一的、官方的模块格式，使其能够在浏览器和服务器端等所有 `JavaScript`环境中使用。
- 特点：
    - 使用 `import` 和 `export` 语法
    - 编译时静态加载，便于静态分析、`Tree Shaking`（摇树优化）
    - 异步加载，也可用于浏览器
- 语法：
    - `import`：用于从其他模块导入功能
    - `export`：用于从当前模块导出功能
    
    ```jsx
    // math.js
    export function add(a, b) {
        return a + b;
    }
    export const PI = 3.14;
    
    // main.js
    import { add, PI } from './math.js';
    console.log(add(PI, 2));
    ```
    
- 优点：
    - 官方标准与统一性
        - 语言层面支持：`ESM` 是 `ECMAScript` 语言标准的一部分，结束了多年来 `AMD`、`CMD`、`CommonJS`、`UMD` 等社区规范混战的局面
        - 环境通用：为浏览器、`Node.js`、`Deno`、`Bun` 等所有 `JavaScript` 运行环境提供了统一的模块语法，降低了上下文切换的成本
    - 静态分析与编译时优化 (由于 `import/export` 必须在顶层作用域，使得模块依赖关系在代码执行前就完全确定)
        - `Tree Shaking`（摇树优化）：打包工具（如 `Webpack`、`Rollup`、`Vite`）可以静态分析出哪些导出值没有被任何模块使用，从而安全地将这些“死代码”从最终打包文件中剔除，极大减小了打包体积
        - 更好的压缩：工具可以进行更激进的变量名混淆和优化
        - 作用域提升（`Scope Hoisting`）：可以将多个模块合并到一个函数作用域中，减少代码量并提升运行时性能
    - 值的实时绑定 (`ESM` 导入的是值的只读引用，而不是值的拷贝)
        - 响应式更新：当导出模块内的值发生变化时，所有导入该值的模块都会立即看到最新结果。这对于维护共享状态、循环依赖管理等场景更加可靠和直观
        - 更符合直觉：避免了 `CommonJS` 中值拷贝可能带来的困惑
    - 原生异步与浏览器友好
        - 设计之初就考虑浏览器：模块的加载和执行默认是异步且非阻塞的
        - 更好的性能：浏览器可以并行下载模块依赖，并通过 `type="module"` 的 `<script>` 标签轻松使用
        - 清晰的依赖图：浏览器可以精确知道需要下载哪些文件
    - 支持循环依赖
        
        `ESM` 的静态引用机制使其能够比 `CommonJS` 更优雅地处理模块间的循环依赖。
        
        由于导入的是引用，即使在循环依赖中，模块也能访问到对方最新导出的接口（尽管在设计和初始化顺序上仍需小心）。
        
    - 严格的模块作用域
        
        每个 `ESM` 模块都拥有自己的顶级作用域，而非全局作用域。
        
        这从根本上解决了全局变量污染的问题，实现了真正的隔离。
        
- 缺点：
    1. 与庞大旧生态的兼容性问题
        - Node.js 生态的过渡阵痛：`npm` 上仍有海量的包使用 `CommonJS` 编写。在 ESM 环境中使用这些包有时会遇到问题（如 `require is not defined`）
        - 互操作规则复杂：在 `Node.js` 中，`ESM` 和 `CommonJS` 的互操作有特定规则（例如，`ESM` 中只能默认导入 `CJS` 模块，`CJS` 中不能直接 `require ESM` 模块，必须用动态`import()`），这增加了心智负担
    2. 路径必须明确
        
        文件扩展名要求：在原生 `ESM` 中（尤其是在 `Node.js` 和某些打包工具中），导入路径通常需要完整的文件扩展名（如 `'./module.js'`），而不能省略为 `'./module'`。这与 `CommonJS` 的习惯不同
        
        相对路径需要 `./`：导入本地模块时，必须使用相对路径（`./ 或 ../`）或绝对路径，不能直接写模块名，否则会被认为是 `npm` 包
        
    3. 静态`import`无法条件导入
        
        由于静态性的要求，标准的 `import` 语句不能放在条件判断或函数内部
        
        解决方案是使用`动态导入 import()`，但它返回一个 `Promise`，语法上更复杂，是异步的
        
    4. 开发环境对构建工具的依赖
        
        虽然浏览器已原生支持 `ESM`，但在实际开发中，几乎必须依赖 `Vite`、`Webpack`、`Snowpack` 等构建工具来获得良好的开发体验。这导致 `ESM` 的“原生”优势在开发环节被工具层所“掩盖”。
        
        - 大量的 `node_modules` 包不是 `ESM` 格式，需要转换
        - 需要处理非 `JS` 资源（如 `CSS`、图片）
        - 没有热更新（`HMR`）
    5. 配置复杂性（尤其在 `Node.js` 中）
        
        在 `Node.js` 中使用 ESM 需要一些配置
        
        - 需要在 `package.json` 中设置 `"type": "module"`，或者使用 `.mjs` 文件扩展名
        - 与旧的 `CommonJS` 工具和模式共存时，配置可能会变得复杂

# **阶段四：规范化时代 - `CommonJS`、`AMD`、`CMD`**

随着服务器端 `JavaScript (Node.js)` 的兴起和前端应用复杂度的提升，模块化规范应运而生。

`AMD vs CMD` 的争论**：**在当时非常激烈，但最终随着 ES6 模块和打包工具的出现而平息。

## **CommonJS - 同步加载，主要用于服务器端**

- 概述：为 JavaScript 在浏览器环境之外（主要指服务器端）制定模块生态标准。它的核心思想是让每个文件都是一个独立的模块，拥有自己的作用域，并通过特定的语法来导入和导出功能。
- 特点：CommonJS 规范是 Node.js 模块系统的基础。在服务器端，所有模块文件都存放在本地硬盘，读取速度非常快，同步加载模块不会造成性能问题。一个文件就是一个模块。
- 语法：
    - 使用 `require` 来加载模块
    - 使用 `module.exports` 来导出接口
    
    ```jsx
    // math.jsfunction add(a, b) { return a + b; }
    module.exports = { add };
    
    // main.jsconst math = require('./math.js');
    console.log(math.add(2, 3));// 5
    ```
    
- 优点：
    1. 语法简单直观：require 和 module.exports 非常容易理解和使用，符合直觉
    2. 依赖管理清晰：模块间的依赖关系一目了然
    3. 适合服务器端：同步加载模块在服务器端是天然合理的，因为 I/O 是同步且快速的
    4. 生态强大：Node.js 的庞大生态系统都构建在 `CommonJS` 之上，有海量的第三方模块可用
- 缺点：
    1. 同步加载不适合浏览器：这是它最核心的缺点。浏览器需要通过网络请求加载文件，同步加载会导致脚本阻塞，页面无响应
    2. 无法进行 Tree Shaking：由于 `module.exports` 是动态的（可以在运行时改变），打包工具（如 `Webpack`）在编译时很难静态分析出哪些导出值被真正使用，因此难以实现完美的 `Tree Shaking` 来剔除无用代码
    3. 模块引用是值的拷贝（对于基本数据类型）：`CommonJS` 模块输出的是值的拷贝。一旦输出，模块内部的变化就影响不到这个值了（对于数字、字符串等基本类型）

## **AMD (Asynchronous Module Definition) - 异步加载，主要用于浏览器端**

- **背景**：
    - CommonJS的局限性：CommonJS 规范（主要用于 Node.js）使用 `require()` 语句来同步加载模块。这在服务器端是可行的，因为模块文件都在本地磁盘，读取速度极快。但在浏览器端，模块文件需要通过网络请求获取，如果采用同步加载，页面会长时间处于“假死”状态，体验极差
    - 前端应用复杂度提升：随着 Ajax 和 Web 2.0 的兴起，前端代码变得越来越复杂，急需一种可靠的模块化方案来组织代码
- 定义：`AMD` 的全称是 `Asynchronous Module Definition`，中文意为“异步模块定义”，它的代表实现是 `RequireJS`。
- 特点：异步加载模块，不影响后面语句的执行
- 语法：
    - `define` 定义模块
    - `require` 加载模块
    
    ```jsx
    // 定义一个依赖 jQuery 的模块
    define(['jquery'], function($) {
    	// 模块代码
    	function doSomething() {
        $('#app').html('Hello');
      }
    	// 返回模块的公开接口
    	return {
        doSomething: doSomething
      };
    });
    
    // 加载并使用模块
    require(['myModule'], function(myModule) {
        myModule.doSomething();
    });
    ```
    
- 优点：
    1. 异步加载，性能友好：不会阻塞浏览器渲染，适合浏览器环境
    2. 依赖前置，关系清晰：模块的所有依赖都在定义时声明，便于工具分析和管理，模块的初始化顺序得到保证
    3. 模块化彻底：支持模块的封装和复用
- 缺点：
    1. 语法相对繁琐：无论是定义模块还是使用模块，都需要嵌套回调函数，代码阅读和书写体验不如 `CommonJS` 和 `ES6 Module` 直观
    2. 不是原生支持：需要引入额外的库（如 `RequireJS`）才能运行
    3. “依赖前置”可能不高效：开发者需要在模块开头就罗列所有依赖（心智负担），即使某些依赖只在函数内部或条件分支中才用到（浪费），但 `AMD` 的依赖前置会导致它无条件提前加载和执行

## **CMD (Common Module Definition) - 通用模块定义，兼顾服务器端和浏览器端**

- **背景**：CMD 是阿里玉伯提出的规范，希望是一种能兼顾服务器端和浏览器端的通用方案。
- 定义：CMD 的全称是 `Common Module Definition`，中文意为“通用模块定义”，代表实现是 `Sea.js`。
- 特点：依赖就近 和 延迟执行
    - AMD 推崇依赖前置：在定义模块时就声明所有依赖。
    - CMD 推崇依赖就近：在需要用到依赖的时候再 `require`。
- 语法：
    
    ```jsx
    // CMD 写法
    define(function(require, exports, module) {
        var a = require('./a');// 依赖就近，用时再声明
        a.doSomething();
        // ...
        var b = require('./b');
        b.doSomething();
    });
    ```
    
- 优点：
    1. 书写自然：代码风格与 `Node.js` 的 `CommonJS` 风格几乎一样，降低了学习成本和迁移成本
    2. 依赖声明直观：依赖在用到的地方附近声明，代码更容易阅读和维护
    3. 性能潜力：理论上，延迟执行可以避免加载暂时用不到的模块，节省了初始化的开销
- 缺点：
    1. 不利于静态分析：由于依赖是散落在代码中的字符串，打包工具在编译时很难像分析 `AMD` 或 `ES6 Module` 那样，轻松地构建出完整的依赖树。这给后续的优化（如 `Tree Shaking`）带来了困难
    2. 模块加载器更复杂：`Sea.js` 需要实现更复杂的逻辑来管理模块的加载和执行顺序，因为依赖关系不是一开始就明确的
    3. 生态不及 AMD：虽然在国内有较大影响力，但全球范围内 `AMD/RequireJS` 的生态更庞大

# **阶段三：IIFE 模式 (Immediately Invoked Function Expression)**

利用函数作用域来创建私有空间，这是模块化思想的雏形。

- 实现方式：通过立即执行函数包裹代码，对外只暴露需要公开的接口
    
    ```jsx
    // moduleA.js(function(global) {
        var privateData = 'I am private';// 私有变量function privateFn() { ... } // 私有函数 // 暴露到全局的公共接口
        global.moduleA = {
            publicApi: function() {
    			// 可以访问私有数据
                console.log(privateData);
            }
        };
    })(window);
    
    // moduleB.js(function(global, moduleA) {// 显式声明依赖
        global.moduleB = {
            doSomething: function() {
                moduleA.publicApi();// 使用 moduleA 的接口}
        };
    })(window, window.moduleA);// 依赖作为参数传入
    ```
    
- 优点：
    1. 实现私有化：函数内部的变量外部无法直接访问
    2. 依赖显式声明：通过函数参数声明依赖，关系更清晰
- 缺点：
    1. 仍然依赖全局变量：模块名（如 `moduleA`）依然是全局的
    2. 脚本加载顺序：依赖的脚本必须提前加载
    3. 无法进行静态分析：工具无法在编译时分析出模块的依赖树

# **阶段二：命名空间模式 (Namespace)**

为了减少全局变量，人们使用一个全局对象来作为命名空间

- 实现方式：将所有模块内容封装到一个全局对象内
    
    ```jsx
    var MYAPP = {
        moduleA: {
            data: 'hello',
            foo: function() { ... }
        },
        moduleB: {
            data: [1, 2, 3],
            bar: function() { ... }
        }
    };
    ```
    
- 优点：一定程度上减少了全局变量，避免了部分命名冲突
- 缺点：本质上对象内部的属性仍然是暴露的，外部代码依然可以修改它们，无法解决根本的封装和依赖问题

# **阶段一：原始时代 - 全局函数模式 (Global Function)**

在早期，JavaScript 代码只是简单地写在 `<script>` 标签里

- 实现方式：定义全局函数和变量。
    
    ```jsx
    // a.js
    function add(a, b) {
        return a + b;
    }
    
    // b.js
    function calculate() {
      add(1, 2);// 依赖全局的 add 函数
    }
    ```
    
- 存在的问题：
    1. 全局污染：所有变量和函数都挂在 `window` 对象下，容易引发命名冲突
    2. 依赖关系不明确：脚本的加载顺序至关重要，但依赖关系是隐式的，难以维护
    3. 可维护性差：随着项目变大，代码会变得混乱不堪