Javascript 模块化理解

原始时代： script标签引入javascript文件

这种方式缺乏依赖解析，全局变量空间污染，而且要保证文件引入的顺序，管理比较混乱

原始时代： 模块对象和IIFE模式

通过使用模块对象和立即调用的函数表达式(IIFE) ，我们可以减少对全局作用域的污染。在这种方法中，我们只向全局作用域公开一个对象。该对象包含了我们在应用程序中需要的所有方法和值。

CommonJs虽然解决的依赖问题，但是CommonJs的问题在于它是同步的，var sum = require('./sum'); 时

当调用 var sum = require('./sum');时，系统将暂停，直到模块准备(ready)完成，这意味着当所有的模块都加载时，这一行代码将阻塞浏览器进程，
因此，这可能不是为浏览器端应用程序定义模块的最佳方式

异步模块时代： AMD

define 函数(或关键字)将依赖项列表和回调函数作为参数。回调函数的参数与数组中的依赖是相同的顺序。这相当于导入模块。并且回调函数返回一个值，即是你导出的值。

CommonJS 和 AMD 解决了模块模式中剩下的两个问题：依赖解析 和 全局作用域污染 。我们只需要处理每个模块或每个文件的依赖关系就可以了,兵器不再有全局作用域污染。

AMD的良好实现： RequireJS 依赖注入

RequireJS 是一个 JavaScript 模块加载器(module loader) 。它可以根据需要异步加载模块，尽管 RequireJS 的名字中含有 require，但是它的目标却并非要去支持 CommonJS 的 require 语法。使用 RequireJS，可以编写 AMD 风格的模块。

爱疯的小疯子

快上车，一起飞

Javascript 模块化理解

原始时代： script标签引入javascript文件

1 2 3 4 5 6 7 8 9 10 11 12 13

-------- html ------- <div id="result"></div> <script type="text/javascript" src="add.js"></script> <script type="text/javascript" src="sum.js"></script> <script type="text/javascript" src="main.js"></script> -------add.js------ function add(a, b){ return a + b ;} ------ sum.js ----- function sum(n){ return n + add(1, 2); } ----- main.js ---- document.getElementById('result').innerHTML = sum(3);

这种方式缺乏依赖解析，全局变量空间污染，而且要保证文件引入的顺序，管理比较混乱

原始时代： 模块对象和IIFE模式

通过使用模块对象和立即调用的函数表达式(IIFE) ，我们可以减少对全局作用域的污染。在这种方法中，我们只向全局作用域公开一个对象。该对象包含了我们在应用程序中需要的所有方法和值。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

例如只向全局作用域公开了 App 对象 -------- html ------- <div id="result"></div> <script type="text/javascript" src="app.js"></script> <script type="text/javascript" src="add.js"></script> <script type="text/javascript" src="sum.js"></script><br data-filtered="filtered"><script type="text/javascript" src="main.js"></script> ------- app.js ------- var App = {}; ------- add.js ------- (function(){ App.add = function(a, b){ return a + b; } })(); ------- sum.js ------- (function(){ App.sum= function(n){ return App.add(1, 2) + n; } })(); ------- main.js ------- (function(app){ document.getElementById('result').innerHTML = app.sum(3); })(App);

可以看到，除了 app.js 以外，其他每个文件都被封装成了 IIFE 格式

依旧存在 缺乏依赖解析的问题，还是有1个全局变量，而不是干掉全部的全局变量

过渡时代：CommonJS

CommonJS 不是一个 JavaScript 库。它是一个标准化组织。它就像 ECMA 或 W3C 一样。ECMA 定义了 JavaScript 的语言规范。W3C定义了 JavaScript web API ，比如 DOM 或 DOM 事件。 CommonJS 的目标是为 web 服务器、桌面和命令行应用程序定义一套通用的 API 。

CommonJS 还定义了模块 API 。因为在服务器应用程序中没有 HTML 页面和 </script><script> 标签，所以为模块提供一些清晰的 API 是很有意义的。模块需要被公开(**export**)以供其它模块使用，并且可以访问(**import**)。它的导出模块语法如下：

1 2 3 4 5 6 7 8 9 10 11 12

---------------- add.js -------------------- module.exports = function add(a, b){ return a+b; } ---------------- sum.js -------------------- var add = require('./add'); module.exports = function sum(n){ return add(1, 2) + n; } ---------------- main.js -------------------- var sum = require('./sum'); document.getElementById('result').innerHTML = sum(3);

CommonJs虽然解决的依赖问题，但是CommonJs的问题在于它是同步的，var sum = require('./sum'); 时

当调用 var sum = require('./sum');时，系统将暂停，直到模块准备(ready)完成，这意味着当所有的模块都加载时，这一行代码将阻塞浏览器进程，
因此，这可能不是为浏览器端应用程序定义模块的最佳方式

异步模块时代： AMD

1 2 3

define([‘add’, ‘sum’], function(add, sum){ document.getElementById.innerHTML = sum(3); });

define 函数(或关键字)将依赖项列表和回调函数作为参数。回调函数的参数与数组中的依赖是相同的顺序。这相当于导入模块。并且回调函数返回一个值，即是你导出的值。

CommonJS 和 AMD 解决了模块模式中剩下的两个问题：依赖解析 和 全局作用域污染 。我们只需要处理每个模块或每个文件的依赖关系就可以了,兵器不再有全局作用域污染。

AMD的良好实现： RequireJS 依赖注入

RequireJS 是一个 JavaScript 模块加载器(module loader) 。它可以根据需要异步加载模块，尽管 RequireJS 的名字中含有 require，但是它的目标却并非要去支持 CommonJS 的 require 语法。使用 RequireJS，可以编写 AMD 风格的模块。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

-------------------- html ---------------------- <div id="result"></div> <!-- 入口文件 --> <script data-main="main" src="require.js"></script> -------------------- main.js ---------------------- define(['sum'], function(sum){ document.getElementById('result').innerHTML = sum(3); }) -------------------- sum.js ---------------------- define(['add'], function(add)){ var sum = function(n){ return add(1,2) + n; } return sum; }) -------------------- add.js ---------------------- // add.js define([], function(){ var add = function(a, b){ return a + b; }; return add; });

浏览器加载 index.html，而 index.html 又加载 require.js 。剩下的文件及其依赖都是由require.js 负责加载。

RequireJS 和 AMD 解决了我们以前所遇到的所有问题。然而，它也带来了一些不那么严重的问题：

1.AMD 的语法过于冗余。因为所有东西都封装在 define 函数中

2.数组中的依赖列表必须与函数的参数列表匹配。如果存在许多依赖项，则很难维护依赖项的顺序

3.在当前浏览器下（HTTP 1.1），加载很多小文件会降低性能

模块打包器： Browserify

可以在浏览器中使用 CommonJS 模块，通过 Browserify 遍历代码的依赖树，并将依赖树中的所有模块打包成一个文件。

不同于 RequireJS ，Browserify 是一个命令行工具，需要依赖 NPM 环境，

困惑的时代： UMD

UMD 是一套用来识别当前环境支持的模块风格的 if/else 语句

无论是JavaScript 全局模块对象，还是 CommonJS 或是 AMD 更是 UMD，都太麻烦了，额外增加了很多工作量，并且不易维护。

光明的时代： ES6模块语法

ES6 用 import和 export 关键字来导入和导出模块

ES6 模块语法是简洁的,虽然目前浏览器并未全部支持，但可以使用一些工具(babel)来转化它

工程化的时代： Webpack

虽然gulp、grunt都号称是工程化开发工具，，但个人感觉他们处理的东西还是比较基础，对于模块依赖打包来说，支持不是非常好，反正我是不喜欢gulp.

Webpack 是一个 模块打包器，就像 Browserify 一样，它会遍历依赖树，然后将其打包到一到多个文件。

它与Browserify 不同之处就是 可以处理 CommonJS 、 AMD 和 ES6 模块，并且 Webpack 还有更多实用的东西，比如 代码分离、加载器、插件

简洁的时代：Rollup

rollup 只会将需要的函数包含到打包文件中，从而显著减少打包文件大小

发现 add.js的 sub() 函数并没有包含在这个打包文件中，因为没有引用它。

个人观点: rollup适合开发一些库，目前rollup的插件支持不是时分丰满，需要与webpack2或gulp结合使用来开发大型项目，对于一些小项目，完全可以rollup来构建，方便快捷。