首先是前端是基于多语言、多层次的编码和组织工作，其次前端产品的交付是基于浏览器，这些资源是通过增量加载的方式运行到浏览器端。
如何在开发环境组织好这些碎片化的代码和资源，并且保证他们在浏览器端快速、优雅的加载和更新，就需要一个模块化系统。
<script>标签
<script src="module1.js"></script>
<script src="module2.js"></script>
<script src="libraryA.js"></script>
<script src="module3.js"></script>
这是最原始的 JavaScript 文件加载方式，如果把每一个文件看做是一个模块，那么他们的接口通常是暴露在全局作用域下，也就是定义在 window对象中，不同模块的接口调用都是一个作用域中。
缺点：
- 全局作用域下容易造成变量冲突
- 文件只能按照 <script>的书写顺序进行加载
- 开发人员必须主观解决模块和代码库的依赖关系
- 在大型项目中各种资源难以管理，长期积累的问题导致代码库混乱不堪
CommonJS
该规范的核心思想是允许模块通过 require 方法来同步加载所要依赖的其他模块，然后通过 exports 或 module.exports 来导出需要暴露的接口。
require("module");
require("../file.js");
exports.doStuff = function() {};
module.exports = someValue;
优点：
- 服务器端模块便于重用
- NPM 中已经有将近20万个可以使用模块包
- 简单并容易使用
缺点：
- 同步的模块加载方式不适合在浏览器环境中，同步意味着阻塞加载，浏览器资源是异步加载的
- 不能非阻塞的并行加载多个模块
实现：
- 服务器端的 Node.js
- Browserify，浏览器端的 CommonJS 实现，可以使用 NPM 的模块，但是编译打包后的文件体积可能很大
- modules-webmake，类似Browserify，还不如 Browserify 灵活
- wreq，Browserify 的前身
友情小Tips：服务器端的 Node.js 遵循 CommonJS规范，在ES6标准发布后module成为标准。标准的使用export指令导出接口，以import引入模块，但是在我们一贯的node模块中，我们仍然采用CommonJs规范。
nodejs v6+ 开始支持 90% 以上的 ES6，however，import还暂不支持。
ES6 模块
EcmaScript6 标准增加了 JavaScript 语言层面的模块体系定义。ES6 模块的设计思想，是尽量的静态化，使得编译时就能确定模块的依赖关系，以及输入和输出的变量。CommonJS 和 AMD 模块，都只能在运行时确定这些东西。
import "jquery";
export function doStuff() {}
module "localModule" {}
优点：
- 容易进行静态分析
- 面向未来的 EcmaScript 标准
缺点：
- 原生浏览器端还没有实现该标准
*全新的命令字，新版的 Node.js才支持
实现：
