前端模块化的演变过程

随着前端的发展，无模块化存在的问题日益显露。但在这个过程中，模块化也是有一定的发展。

stage1-文件划分方式

根据业务或功能封装某一类变量或者函数；

约定每一个文件都是一个模块；

当使用到这个模块的时候，通过script标签引入到html页面中，直接使用模块中的成员(变量|函数)；

但当代码体积达到一定量的时候，这种方法的缺点就很明显了。

//module-a.js
// module a 相关状态数据和功能函数

var name = 'module-a'

function method1 () {
  console.log(name + '#method1')
}

function method2 () {
  console.log(name + '#method2')
}

//module-b.js
// module b 相关状态数据和功能函数

var name = 'module-b'

function method1 () {
  console.log(name + '#method1')
}

function method2 () {
  console.log(name + '#method2')
}

//index.html
  <script src="module-a.js"></script>
  <script src="module-b.js"></script>
  <script>
    // 命名冲突
    method1()
    // 模块成员可以被修改
    name = 'foo'
  </script>

缺点：

全部变量都暴露在全局作用域中，没有私有空间，所有成员都可被外部访问或者修改
当模块达到一定数量，通过约定的方式很难避免变量冲突
无法管理模块与模块之间的依赖关系

stage2-命名空间的方式

每个模块只暴露一个全局对象，所有的成员都挂载到这个全局对象上

//module-a.js
var moduleA = {
  name: 'module-a',

  method1: function () {
    console.log(this.name + '#method1')
  },

  method2: function () {
    console.log(this.name + '#method2')
  }
}

//module-b.js
var moduleB = {
  name: 'module-b',

  method1: function () {
    console.log(this.name + '#method1')
  },

  method2: function () {
    console.log(this.name + '#method2')
  }
}

//index.html
  <script src="module-a.js"></script>
  <script src="module-b.js"></script>
  <script>
    moduleA.method1()
    moduleB.method1()
    // 模块成员可以被修改
    moduleA.name = 'foo'
  </script>

优点：

通过“命名空间”减小了命名冲突的可能

缺点：

模块内部的成员依然在外部可以被访问和修改

模块之间的依赖关系依然不明确

stage3-通过立即执行函数(IIFE)为模块提供私有空间

具体做法就是将模块内的代码放在一个立即执行函数中

若想把某个成员暴露出去，就把该成员挂载到window中

//module-a.js
;(function () {
  var name = 'module-a'

  function method1 () {
    console.log(name + '#method1')
  }

  function method2 () {
    console.log(name + '#method2')
  }

  window.moduleA = {
    method1: method1,
    method2: method2
  }
})()

//module-b.js
;(function ($) {
  var name = 'module-b'

  function method1 () {
    console.log(name + '#method1')
  }

  function method2 () {
    console.log(name + '#method2')
  }

  window.moduleB = {
    method1: method1,
    method2: method2
  }
  console.log($('#a').html());
})(jQuery)

//index.html
 <script src="module-a.js"></script>
  <script src="module-b.js"></script>
  <script>
    moduleA.method1()
    moduleB.method1()
    // 模块私有成员无法访问
    console.log(moduleA.name) // => undefined
  </script>

优点：

实现了成员私有化，模块内的变量外界不能随意访问

通过立即执行函数，可以传递该模块所依赖的模块，使模块对外部的依赖更加清晰

小结：综上所述，随着模块化的发展，之前所提到的问题也逐一被解决，但还是存在一部分没有解决的问题。先前所有模块都是通过script标签引入的。若我们需要某个模块时，通过script标签引入了该模块，但可能会忘记引入该模块所依赖的模块。或者当我们删除某个模块时，我们也可能会忘记该模块所依赖的模块。

stage4-模块化规范的出现

1.CommonJS

特点：

1.一个文件就是一个模块

2.每个模块都有一个单独的作用域

　　 3.每个模块暴露出去的成员都由module.exports导出

4.使用其他模块的成员时使用require函数导入

CommonJS规范主要引用在Node项目中，该规范加载模块时同步加载，倘若用在浏览器中，会有大量的同步请求导致应用比较慢，但在Node中不会有问题（因为Node是启动时加载模块）

2.AMD规范（Asynchronous Module Definition）

代表库：require.js

特点:

不同于CommonJS的同步加载，该模块可以异步加载模块，提高程序在浏览器的执行效率

但使用起来相对复杂

3.CMD规范（ Common Module Definition ）

代表库：Sea.js

特点：

使用上类似于require.js，写法类似于CommonJS,算是个重复的轮子

4.ES Modules(ES2015的新语法)

特点：

语言层面推出的新语法，比较完善

满足在web端开发使用模块化的需求

综上所述：目前前端模块化基本统一成了CommonJS(Node.js)和ES Modules(浏览器端开发)，我们只需掌握这两种规范开发即可，后续会对着两个模块重点展开讨论

RisingSunBlogs