AMD 与 CMD

AMD 与 CMD

最近小时光项目中需要引用一个插件, 公司用的是sea.js, 就需要把这个JS 改造成 CMD 模式的格式封装,今天在里补充一下模块化相关的知识。

下面介绍几种 JS 的模块化的规范。

script标签

这是最原始的 JavaScript 文件加载方式,如果把每一个文件看做是一个模块,那么他们的接口通常是暴露在全局作用域下,也就是定义在 window 对象中,不同模块的接口调用都是一个作用域中,一些复杂的框架,会使用命名空间的概念来组织这些模块的接口。

缺点:

  • 污染全局作用域
  • 开发人员必须主观解决模块和代码库的依赖关系
  • 文件只能按照script标签的书写顺序进行加载
  • 在大型项目中各种资源难以管理,长期积累的问题导致代码库混乱不堪

CommonJS规范

该规范的核心思想是允许模块通过require方法来同步加载所要依赖的其他模块,然后通过exports或module.exports来导出需要暴露的接口。

require("fullPage");
require("../abc.js");
exports.doStuff = function() {};
module.exports = someValue;

优点:

  • 简单并容易使用
  • 服务器端模块便于重用

缺点:

  • 同步的模块加载方式不适合在浏览器环境中,同步意味着阻塞加载,浏览器资源是异步加载的
  • 不能非阻塞的并行加载多个模块

module.exports与exports的区别

  • exports 是指向的 module.exports 的引用
  • module.exports 初始值为一个空对象 {},所以 exports 初始值也是 {}
  • require() 返回的是 module.exports 而不是 exports

exports示例:

// app.js
var circle = require('./circle');
console.log(circle.area(4));
// circle.js
exports.area = function(r) {
  return r * r * Math.PI;
}

module.exports示例:

// app.js
var area = require('./area');
console.log(area(4));
// area.js
module.exports = function(r) {
  return r * r * Math.PI;
}

AMD规范

AMD标准中定义了以下两个API

require([module], callback);
define(id, [depends], callback);

require接口用来加载一系列模块,define接口用来定义并暴露一个模块。

define("module", ["dep1", "dep2"], function(d1, d2) {
  return someExportedValue;
});
require(["module", "../file"], function(module, file) { /* ... */ });

优点:

  • 适合在浏览器环境中异步加载模块
  • 可以并行加载多个模块

缺点:

  • 提高了开发成本,代码的阅读和书写比较困难,模块定义方式的语义不顺畅
  • 不符合通用的模块化思维方式,是一种妥协的实现

CMD规范

CMD(Common Module Definition)规范和AMD很相似,尽量保持简单,并与CommonJS和Node.js的 Modules 规范保持了很大的兼容性。在CMD规范中,一个模块就是一个文件。

define(function(require, exports, module) {
  var $ = require('jquery');
  var Spinning = require('./spinning');
  exports.doSomething = ...
  module.exports = ...
})

优点:

  • 依赖就近,延迟执行
  • 可以很容易在 Node.js 中运行

缺点:

  • 依赖 SPM 打包,模块的加载逻辑偏重

AMD和CMD的区别

  • 对于依赖的模块,AMD是提前执行,CMD是延迟执行
  • AMD推崇依赖前置;CMD推崇依赖就近,只有在用到某个模块的时候再去require。
// AMD
define(['./a', './b'], function(a, b) {  // 依赖必须一开始就写好  
   a.doSomething()    
   // 此处略去 100 行    
   b.doSomething()    
   ...
});



// CMD
define(function(require, exports, module) {
   var a = require('./a')   
   a.doSomething()   
   // 此处略去 100 行   
   var b = require('./b') 
   // 依赖可以就近书写   
   b.doSomething()
   // ... 
});
  • AMD 的 API 默认是一个当多个用,CMD 的 API 严格区分,推崇职责单一

ES6模块化

EcmaScript6标准增加了JavaScript语言层面的模块体系定义。ES6 模块的设计思想,是尽量的静态化,使得编译时就能确定模块的依赖关系,以及输入和输出的变量。CommonJS和AMD模块,都只能在运行时确定这些东西。

在 ES6 中,我们使用export关键字来导出模块,使用import关键字引用模块。需要说明的是,ES6的这套标准和目前的标准没有直接关系,目前也很少有JS引擎能直接支持。因此Babel的做法实际上是将不被支持的import翻译成目前已被支持的require。

尽管目前使用import和require的区别不大(本质上是一回事),但依然强烈推荐使用import关键字,因为一旦JS引擎能够解析ES6的import关键字,整个实现方式就会和目前发生比较大的变化。如果目前就开始使用import关键字,将来代码的改动会非常小。

import "jquery";
export function doStuff() {}
module "localModule" {}

优点:

  • 容易进行静态分析
  • 面向未来的 EcmaScript 标准

优点:

  • 原生浏览器端还没有实现该标准
  • 全新的命令字,新版的 Node.js才支持