第一阶段：无模块化
JavaScript最初的作用仅仅是验证表单，后来会添加一些动画，但是这些js代码很多在一个文件中就可以完成了，所以，我们只需要在html文件中添加一个script标签。
后来，随着前端复杂度提高，为了能够提高项目代码的可读性、可扩展性等，我们的js文件逐渐多了起来，不再是一个js文件就可以解决的了，而是把每一个js文件当做一个模块。
大概是下面这样：
<script src="jquery.js"></script><script src="jquery_scroller.js"></script><script src="main.js"></script>
优点
比于使用一个js文件，这种多个js文件实现最简单的模块化的思想是进步的
缺点
污染全局作用域。 因为每一个模块都是暴露在全局的，简单的使用，会导致全局变量命名冲突，当然，我们也可以使用命名空间的方式来解决。
对于大型项目，各种js很多，开发人员必须手动解决模块和代码库的依赖关系，后期维护成本较高。依赖关系不明显，不利于维护。 比如main.js需要使用jquery，但是，从上面的文件中，我们是看不出来的，如果jquery忘记了，那么就会报错。
第二阶段： CommonJS规范
CommonJS就是一个JavaScript模块化的规范，该规范最初是用在服务器端的node的，前端的webpack也是对CommonJS原生支持的。
根据这个规范，每一个文件就是一个模块，其内部定义的变量是属于这个模块的，不会对外暴露，也就是说不会污染全局变量。
CommonJS的核心思想就是通过 require 方法来同步加载所要依赖的其他模块，然后通过 exports 或者 module.exports 来导出需要暴露的接口。
规范
- 通过module.exports或exports来暴露模块
-
特点
同步加载，一般用于node端
- 一次加载，多次使用。对同一个模块而言，只会运行一次，多次使用时会从缓存中获取
- 模块加载的顺序，按照它出现的顺序
- 代码都运行在模块作用域，不会造成全局污染
简单应用
```javascript var example = require(‘./a.js’);var x = 5;var addX = function (value) {return value + x;};module.exports.x = x;module.exports.addX = addX;
console.log(example.x); // 5 console.log(example.addX(1)); // 6
注意：当被暴露的对象是单一的值时，不能通过exports来暴露，只能通过module.exports来暴露```javascriptvar x = 5module.exports.x = x //不能使用exports.x = x
优点
CommonJS规范在服务器端率先完成了JavaScript的模块化，解决了依赖、全局变量污染的问题，这也是js运行在服务器端的必要条件。
缺点
这篇文章我们讲的主要是浏览器端js的模块化， 由于 CommonJS 是同步加载模块的，在服务器端，文件都是保存在硬盘上，所以同步加载没有问题，但是对于浏览器端，需要将文件从服务器端请求过来，那么同步加载就不适用了，所以，CommonJS是不适用于浏览器端的。
第三阶段： AMD规范
之前提到: CommonJS规范加载模块是同步的，也就是说，只有加载完成，才能执行后面的操作。AMD规范则是非同步加载模块，允许指定回调函数。由于Node.js主要用于服务器编程，模块文件一般都已经存在于本地硬盘，所以加载起来比较快，不用考虑非同步加载的方式，所以CommonJS规范比较适用。但是，如果是浏览器环境，要从服务器端加载模块，这时就必须采用非同步模式，因此浏览器端一般采用AMD规范。
AMD是一种异步加载模块的方式，主要用在浏览器环境中。主要依赖于require.js库，是requireJs在推广过程中生产的对模块定义的规范。
规范
- 通过define()方法定义模块
require([module], callback) - 通过require方法加载模块
define(id, [depends], callback)
- 先加载require.js ```javascript //通过这种方式先加载requirejs
//为防止加载require.js阻塞页面，可以将其写在页面的底部，或写成以下这种形式 //async属性表明要异步加载，避免网页失去响应，IE不支持这个属性，为兼容IE,所以需要添加defer属性
2. 创建一个主文件(入口文件)
```javascript
//创建一个main.js,我们要写的代码从这里开始
//在html里导入以下js
<script src="js/require.js" data-main="js/main"></script>
//data-main的作用时指出我们的入口文件在哪,require.js会第一个加载主文件
- 主文件的写法 ```javascript //若主模块不依赖于其他模块，则不必要使用requirejs
//一般而言，主模块要依赖于其他模块，需要使用AMD的require方法来加载依赖的模块
require([‘moduleA’, ‘moduleB’, ‘moduleC’], function (moduleA, moduleB, moduleC){
// some code here
}); // require第一个参数是一个数组，表示依赖的模块，第二个参数是一个回调，回调的参数表示对应的模块， // 这样在回调中就可以使用这些模块了 // 它的回掉函数只有在所有模块都加载完成才开始执行
4. 在主模块中配置模块加载的一些行为(通过require.config()方法)
```javascript
require.config({
paths: {
"jquery": "lib/jquery.min",
"underscore": "lib/underscore.min",
"backbone": "lib/backbone.min"
}
});
//require配置一般写在main.js入口文件的顶部
//paths属性表示要加载的文件的路径，可以写本地路径，或服务器路径
//baseUrl属性可以用来改变基目录，上面代码可用以下方式表示
require.config({
baseUrl: "js/lib",
paths: {
"jquery": "jquery.min",
"underscore": "underscore.min",
"backbone": "backbone.min"
}
});
定义模块(通过define()方法)
//通过define来定义模块, //如果该模块还依赖其他模块，则第一个参数是一个数组，表示其依赖的模块 define(['package/lib'], function(lib){ function foo(){ lib.log('hello world!'); } return { foo: foo }; });//在其他模块使用a.js require(['a'], function (a){ a.foo() });优点
- 适合在浏览器环境中异步加载模块
-
缺点
提高了开发成本，并且不能按需加载，而是必须提前加载所有的依赖
第四阶段：CMD规范
CMD规范是阿里的玉伯提出来的，实现js库为sea.js。 它和requirejs非常类似，即一个js文件就是一个模块，但是CMD的加载方式更加优秀，是通过按需加载的方式，而不是必须在模块开始就加载所有的依赖。
定义方法
define(function(){require,exports, module})
require：导入其他依赖的办法
- exports：导出的方法
CMD导出的三种方式
使用exports导出
```javascript //使用define定义模块，require、exports、module是define自带的 define(function(require, exports, module){ //定义导出的方法 function minus(a, b) {
} // 使用exports导出 exports.minus = minus })return a - b
<a name="vGOUI"></a>
### 使用module导出
```javascript
//使用define定义模块，require、exports、module是define自带的
define(function(require, exports, module){
//定义导出的方法
function minus(a, b) {
return a - b
}
// 使用module.exports导出
module.exports = {
minus
}
})
使用return 返回
//使用define定义模块，require、exports、module是define自带的
define(function(require, exports, module){
//定义导出的方法
function minus(a, b) {
return a - b
}
// 使用return导出
return {
minus
}
})
用同一种方法导入
let common= require('./common') // 文件相对路径
//调用减法的方法
console.log(common.minus(5,4))
//结果：１
优点
- 同样实现了浏览器端的模块化加载
- 可以按需加载，依赖就近
缺点
依赖SPM打包，模块的加载逻辑偏重。AMD和CMD的区别
前者是对于依赖的模块提前执行，而后者是延迟执行。 前者推崇依赖前置，而后者推崇依赖就近，即只在需要用到某个模块的时候再require。 如下： ```javascript // 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()
// …
});
<a name="TAqVc"></a>
# 第五阶段： ES6模块化
之前的几种模块化方案都是前端社区自己实现的，只是得到了大家的认可和广泛使用，而ES6的模块化方案是真正的规范。 在ES6中，我们可以使用 import 关键字引入模块，通过 exprot 关键字导出模块，功能较之于前几个方案更为强大，也是我们所推崇的，但是由于ES6目前无法在浏览器中执行，所以，我们只能通过babel将不被支持的import编译为当前受到广泛支持的 require。
<a name="AwKNo"></a>
## 规范
- 一个模块就是一个独立的文件。该文件内部的所有变量，外部无法获取。
- export 命令用于规定模块的对外接口。
- import 命令用于输入其他模块提供的功能
<a name="o7XDb"></a>
## 导入导出方式
<a name="Ta0sI"></a>
### export
导出
```javascript
function minus(a,b) {
return a-b
}
// 使用export，一定要使用{}导出，否则会报错
export {
minus
}
导入
// import 后采用大括号导入，大括号中是变量名，变量名要跟导出的名称一致
// from 后跟文件文件路径 这里是相对路径
import {minus} from './common.js'
//调用方法
minus(5,4) //结果：1
//另一种导入方式 意思就是全部导入 as为重命名为导入的变量重新取一个名字
import * as common from './common.js'
// 调用方式
common.minus(5,4) //结果：1
export default
导出
function minus(a,b) {
return a-b
}
// 使用export default 后不用使用{}
export default minus
导入
// import 后不采用{}导入，后跟的变量名可以随意更改，想取什么取什么
// from 后跟文件文件路径 这里是相对路径
import minus from './common.js'
//调用方法
minus(5,4) //结果：1
//我改为另一个名称
import common from './common.js'
// 调用方式
common(5,4) //结果：1
CommonJS、AMD、CMD、ES6比较
- CommmonJS用于node端，是同步加载的
- AMD依赖于require.js，是异步加载的，是提前加载，立即加载
- CMD依赖于sea.js，是异步加载，延后加载，就近加载，用时加载
- ES6是ES2015的简称，一般通过export来暴露模块，import来导入模块
若有收获，就点个赞吧
0 人点赞
