如何正确理解javascript的模块化

模块化在项目中十分的重要，一个复杂的项目肯定有很多相似的功能模块，如果每次都需要重新编写模块肯定既费时又耗力。但是引用别人编写模块的前提是要有统一的“打开姿势”，如果每个人有各自的写法，那么肯定会乱套，下面介绍几种js的模块化的规范。

一:模块化进程一：script标签

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

缺点:

1、污染全局作用域

2、开发人员必须主观解决模块和代码库的依赖关系

3、文件只能按照script标签的书写顺序进行加载

4、在大型项目中各种资源难以管理，长期积累的问题导致代码库混乱不堪

二:模块化进程二：commonjs规范

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

require("module");
require("../file.js");
exports.dostuff = function(){};
module.exports = somevalue;

优点：

1、简单并容易使用

2、服务器端模块便于重用

缺点:

1、同步的模块加载方式不适合在浏览器环境中，同步意味着阻塞加载，浏览器资源是异步加载的

2、不能非阻塞的并行加载多个模块

module.exports与exports的区别

1、exports 是指向的 module.exports 的引用

2、module.exports 初始值为一个空对象 {}，所以 exports 初始值也是 {}

3、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;
}

错误的情况：

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

其实是对 exports 进行了覆盖，也就是说 exports 指向了一块新的内存（内容为一个计算圆面积的函数），也就是说 exports 和 module.exports 不再指向同一块内存，也就是说此时 exports 和 module.exports 毫无联系，也就是说 module.exports 指向的那块内存并没有做任何改变，仍然为一个空对象{}，也就是说area.js导出了一个空对象，所以我们在 app.js 中调用 area(4) 会报 typeerror: object is not a function 的错误。

总结：当我们想让模块导出的是一个对象时， exports 和 module.exports 均可使用（但 exports 也不能重新覆盖为一个新的对象），而当我们想导出非对象接口时，就必须也只能覆盖 module.exports 。

三:模块化进程三：amd规范

由于浏览器端的模块不能采用同步的方式加载，会影响后续模块的加载执行，因此amd(asynchronous module definition异步模块定义)规范诞生了。

amd标准中定义了以下两个api

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

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

示例：

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

优点：

1、适合在浏览器环境中异步加载模块

2、可以并行加载多个模块

缺点：

1、提高了开发成本，代码的阅读和书写比较困难，模块定义方式的语义不顺畅

2、不符合通用的模块化思维方式，是一种妥协的实现

四:模块化进程四：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 = ...
})

优点：

1、依赖就近，延迟执行

2、可以很容易在 node.js 中运行

缺点：

1、依赖 spm 打包，模块的加载逻辑偏重

amd和cmd的区别

amd和cmd起来很相似，但是还是有一些细微的差别，让我们来看一下他们的区别在哪里：

1、对于依赖的模块，amd是提前执行，cmd是延迟执行。

2、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()
  // ...
});

3、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 functiondostuff(){}
module "localmodule" {}

优点：

1、容易进行静态分析

2、面向未来的 ecmascript 标准

缺点：

1、原生浏览器端还没有实现该标准

2、全新的命令字，新版的 node.js才支持

以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，同时也希望多多支持！