转自:https://www.imooc.com/article/20057 很清楚明白的帮我理顺了思路。javascript
随着前端js代码复杂度的提升,JavaScript模块化
这个概念便被提出来,前端社区也不断地实现前端模块化,直到es6对其进行了规范,下面就介绍JavaScript模块化
。html
JavaScript模块化是如何一步一步地发展起来的,而且也会主要对这些模块化方式作一个简单的比较。前端
第一阶段:无模块化vue
JavaScript最初的做用仅仅是验证表单,后来会添加一些动画,可是这些js代码不少在一个文件中就能够完成了,因此,咱们只须要在html文件中添加一个script标签
。java
后来,随着前端复杂度提升,为了可以提升项目代码的可读性
、可扩展性
等,咱们的js文件逐渐多了起来,再也不是一个js文件就能够解决的了,而是把每个js文件当作一个模块。那么,这时的js引入方式是怎样的呢?大概是下面这样:node
<script src="jquery.js"></script> <script src="jquery_scroller.js"></script> <script src="main.js"></script> <script src="other1.js"></script> <script src="other2.js"></script> <script src="other3.js"></script>
即简单的将全部的js文件通通放在一块儿。可是这些文件的顺序还不能出错,好比jquery须要先引入,才能引入jquery插件,才能在其余的文件中使用jquery。jquery
优势:webpack
相比于使用一个js文件,这种多个js文件实现最简单的模块化的思想是进步的。 ios
缺点:es6
污染全局做用域。 由于每个模块都是暴露在全局的,简单的使用,会致使全局变量命名冲突,固然,咱们也可使用命名空间的方式来解决。
对于大型项目,各类js不少,开发人员必须手动解决模块和代码库的依赖关系,后期维护成本较高。
依赖关系不明显,不利于维护。 好比main.js须要使用jquery,可是,从上面的文件中,咱们是看不出来的,若是jquery忘记了,那么就会报错。
第二阶段: CommonJS规范
CommonJS就是一个JavaScript模块化的规范,该规范最初是用在服务器端的node
的,前端的webpack
也是对CommonJS原生支持的。
根据这个规范,每个文件就是一个模块,其内部定义的变量是属于这个模块的,不会对外暴露,也就是说不会污染全局变量。
CommonJS的核心思想就是经过 require 方法来同步加载所要依赖的其余模块,而后经过 exports 或者 module.exports 来导出须要暴露的接口
。以下所示:
// a.js var x = 5; var addX = function (value) { return value + x; }; module.exports.x = x; module.exports.addX = addX;
这里的a.js
就是一个CommonJS规范的模块了。 这里的module就表明了这个模块,module的exports属性就是对外暴露的接口,能够对外导出外部能够访问的变量,好比这里的x
和addX
。
exports 是对 module.exports 的引用。好比咱们能够认为在一个模块的顶部
有这句代码:
exports = module.exports
因此,咱们不能直接给exports赋值,好比number、function等。
而后咱们就能够在其余模块中引入这个模块使用了:
var a = require('./a.js'); console.log(example.x); // 5 console.log(example.addX(1)); // 6
这里的require就会获取到a.js所暴露的module.exports变量,而后就可使用其暴露的x和addX了。
优势:
CommonJS规范在服务器端率先完成了JavaScript的模块化,解决了依赖、全局变量污染的问题,这也是js运行在服务器端的必要条件。
缺点:
此文主要是浏览器端js的模块化, 因为 CommonJS 是同步加载模块的,在服务器端,文件都是保存在硬盘上,因此同步加载没有问题,可是对于浏览器端,须要将文件从服务器端请求过来,那么同步加载就不适用了,因此,CommonJS是不适用于浏览器端的。
第三阶段: AMD规范
以前提到: CommonJS规范加载模块是同步
的,也就是说,只有加载完成,才能执行后面的操做。AMD规范则是非同步
加载模块,容许指定回调函数
。因为Node.js主要用于服务器编程,模块文件通常都已经存在于本地硬盘,因此加载起来比较快,不用考虑非同步加载的方式,因此CommonJS规范比较适用。可是,若是是浏览器环境,要从服务器端加载模块,这时就必须采用非同步模式,所以浏览器端通常采用AMD规范。而AMD规范的实现,就是大名鼎鼎的require.js
了。
AMD标准中,定义了下面两个API:
1.require([module], callback) 2. define(id, [depends], callback)
即经过define
来定义一个模块,而后使用require
来加载一个模块。 而且,require还支持CommonJS的模块导出方式。
定义alert模块:
define(function () { var alertName = function (str) { alert("I am " + str); } var alertAge = function (num) { alert("I am " + num + " years old"); } return { alertName: alertName, alertAge: alertAge }; });
引入模块:
require(['alert'], function (alert) { alert.alertName('JohnZhu'); alert.alertAge(21); });
可是,在使用require.js的时候,咱们必需要提早加载全部的依赖,而后才可使用,而不是须要使用时再加载。
优势:
适合在浏览器环境中异步加载模块。能够并行加载多个模块。
缺点:
提升了开发成本,而且不能按需加载,而是必须提早加载全部的依赖。
第四阶段:CMD规范
CMD规范是阿里的玉伯提出来的,实现js库为sea.js
。 它和requirejs很是相似,即一个js文件就是一个模块,可是CMD的加载方式更加优秀,是经过按需加载
的方式,而不是必须在模块开始就加载全部的依赖。以下:
define(function(require, exports, module) { var $ = require('jquery'); var Spinning = require('./spinning'); exports.doSomething = ... module.exports = ... })
优势:
一样实现了浏览器端的模块化加载。
能够按需加载,依赖就近。
缺点:
依赖SPM打包,模块的加载逻辑偏重。
其实,这时咱们就能够看出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.doSomthing() //... });
第五阶段: ES6模块化
以前的几种模块化方案都是前端社区本身实现的,只是获得了你们的承认和普遍使用,而ES6的模块化方案是真正的规范。 在ES6中,咱们可使用 import
关键字引入
模块,经过 export
关键字导出
模块,功能较之于前几个方案更为强大,也是咱们所推崇的,可是因为ES6目前没法在浏览器中执行,因此,咱们只能经过babel
将不被支持的import编译为当前受到普遍支持的 require。
虽然目前import和require的区别不大,可是仍是推荐使用使用es6,由于将来es6一定是主流,对于代码的迁移成本仍是很是容易的。 如:
import store from '../store/index' import {mapState, mapMutations, mapActions} from 'vuex' import axios from '../assets/js/request' import util from '../utils/js/util.js' export default { created () { this.getClassify(); this.RESET_VALUE(); console.log('created' ,new Date().getTime()); }