好久没有做过传统网页开发了，这次帮朋友处理的时候用了很多经典插件。在用到 popper 的时候，发现引用地址里分成了 esm、 cjs、 umd 三个路径，我这种半路出家的猿????只熟悉 amd 异步模块定义，都不知道这三个是什么。直觉告诉我这里面既然出现了跟 amd 这么相似的 umd，那么跟模块化多少有点关系。赶紧搜索了解学习一下。

(相关资料图)

学习过程发现最直观的还是看代码。其实几个模式我都用过，只是不知道叫什么，但是只需要看一眼代码，立刻就能找到对应的技术路径分支。

ESM （ES Module：异步导入）

1

2

3

4

5

6

import {foo, bar} from "./myLib";

...

exportdefault function {...};

exportconst function1 {...};

exportconst function2 {...};

对我来说这个形式非常熟悉，因为近几年大量开发 vue、混合app 和 小程序。

个人简单理解：

1、ES 模块是 Javascript 提出的实现一个标准模块系统的方案。

2、具有 CJS 的简单语法和 AMD 的异步。

3、ESM 允许打包器删除不必要的代码，减少代码包可以获得更快的加载。

4、得益于 ES6 的静态模块结构，可以进行 Tree Shaking （例如根据rollup阶段做的标记，进行代码收集，最后生成真正用到的代码，对优化非常友好）。

CJS （CommonJS：同步导入模块）

1

2

3

const doSomething = require("./doSomething.js");

module.exports = functiondoSomething(n) {...}

显然，我们熟知的 NodeJS 就是使用的 CJS 模式。

个人简单理解：

1、CJS 不能在浏览器中工作。它必须经过转换和打包。

2、在 CJS 中每一个 js 文件都是一个单独的模块。

3、CJS 规范加载模块是同步的，只有加载完成，才能执行后面的操作。

4、所有代码都运行在模块作用域，不会污染全局作用域。

5、模块可以多次加载，但是只会在第一次加载时运行一次，然后运行结果就被缓存了，以后再加载，就直接读取缓存结果。要想让模块再次运行，必须清除缓存。

AMD （Asynchronous Module Definition：异步模块定义）

1

2

3

define(["dep1", "dep2"], function (dep1, dep2) {

return function {};

});

可能新时代的 Javascripter 不是很熟悉这个模式了，但是作为老人来说，应该是再熟悉不过了，在那个 ESM 还空缺的状态，AMD 简直就是这个领域的救星，例如经典的 RequireJS。

个人简单理解：

1、AMD 允许异步加载模块，并且在加载完成后执行模块的代码。

2、AMD 可以按需加载模块，并且在加载模块时并行执行其他任务，从而提升应用的性能。

3、实现js文件的异步加载，避免网页失去响应；管理模块之间的依赖性，便于代码的编写和维护。

4、AMD 主要作为前端应用，现在已经较少使用。

UMD（Universal Module Definition：通用模块定义）

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

(function (root, factory) {

// AMD

if (typeof define === "function" && define.amd) {

define(["jquery", "underscore"], factory);

}

// CJS

else if (typeof exports === "object") {

module.exports = factory(require("jquery"), require("underscore"));

}

// 浏览器全局变量(root 即 window)

else {

root.returnExports = factory(root.jQuery, root._);

}

}(this, function ($, _) { // 方法

functiona{}; // 私有方法，因为它没被返回 (见下面)

functionb{}; // 公共方法，因为被返回了

functionc{}; // 公共方法，因为被返回了

// 暴露公共方法

return {

b: b,

c: c

}

}));

最开始看 UMD 规范的时候，第一感受：这是一坨什么????。但是自己看了以后发现，这????好像我还挺熟的。

没错，因为前几个月之前修复一个2018年的链游时，为了服务端（NodeJS）和网站（RequireJS）能公用一些模块，我就干了类似的事情。

个人简单理解：

1、UMD 让模块能在javascript所有运行环境中发挥作用。

2、UMD 最外层是一个自执行函数，这个自执行函数最终可以导出一个模块。

3、它最少包含了适配 AMD 、 CJS 的模块输出。

4、它主要被用于一些第三方库，随着 AMD 应用的逐渐减少，UMD 也会越来越不重要。

体会

其实每个时代都有自己的思想和规范，因为程序入门的时候就走的前端方向，与服务端技术更替的速度相比，前端更是瞬息万变，稍有不注意就会落伍。

曾经跟技术朋友讨论过关于技术迭代的问题，因为不停学习和淘汰也是一件相当耗费精力和时间的事情。但是最后我们还是必须要学起来，有时候更替的不只是技术，更重要的是一种思想。

[2022年12月30日原始发布于本作者博客]