在最近阅读webpack源码和工作机制的过程中再一次认识JS模块化。
首先，为什么模块化概念对webpack如此重要？
webpack的文档给出了这样一段概念：
本质上，webpack 是一个现代 JavaScript 应用程序的静态模块打包器(module bundler)。当 webpack 处理应用程序时，它会递归地构建一个依赖关系图(dependency graph)，其中包含应用程序需要的每个模块，然后将所有这些模块打包成一个或多个 bundle
在webpack的世界里，一切皆模块
那么模块是什么？
在模块化编程中，开发者将程序分解成离散功能块(discrete chunks of functionality)，并称之为模块。每个模块具有比完整程序更小的接触面，使得校验、调试、测试轻而易举。 精心编写的模块提供了可靠的抽象和封装界限，使得应用程序中每个模块都具有条理清楚的设计和明确的目的。
webapck使用loader通过 loader 可以支持各种语言和预处理器编写模块，将一切资源文件变成模块
-
ES2015
import语句 -
CommonJS
require()语句 -
AMD
define和require语句 - css/sass/less 文件中的
@import语句。 - 样式(
url(...))或 HTML 文件(<img src=...>)中的图片链接(image url)
那么JS中的模块化概念是什么
其实大家是愿意把模块写在一个JS文件里面的，但是解决不了命名冲突的问题，如果写成不同的JS文件，就会难以维护，依赖模糊，请求过多...
为什么我们在JS中需要模块化
- 分解功能拆分代码
- 简化开发便于调试
- 解决命名空间冲突
- 管理依赖
Stage1： IIFE 现代模块化的基石
var myRevealingModule = (function () {
var privateVar = "Ben Cherry",
publicVar = "Hey there!";
function privateFunction() {
console.log( "Name:" + privateVar );
}
function publicSetName( strName ) {
privateVar = strName;
}
function publicGetName() {
privateFunction();
}
// Reveal public pointers to
// private functions and properties
return {
setName: publicSetName,
greeting: publicVar,
getName: publicGetName
};
})();
myRevealingModule.setName( "Paul Kinlan" );
这种模式在JS模块化历程中使用了很长一段时间，它利用JS中唯一的函数作用域对变量进行封装（ES2015之前）
优点
- 很简单，可以在任何地方实现（没有库，不需要语言支持）。
- 可以在单个文件中定义多个模块。
缺点
- 无法以编程方式导入模块（除非使用eval）。
- 需要手动处理依赖关系——JS中的文件经常各种依赖。
- 无法异步加载模块——这对浏览器可很重要。
- 循环依赖可能很麻烦。
- 静态代码分析器很难分析它。
Stage2：CommonJS和Node
CommonJS是一个旨在定义一系列规范的项目，以帮助开发服务器端JavaScript应用程序。CommonJS团队试图解决的一个领域是模块。
NodeJS遵循一部分的CommonJS规范，但是又不完全相同，在于CommonJS中使用export进行导出模块，而NodeJS使用module.export
优点
- 简单：开发人员可以在不查看文档的情况下掌握概念。
- 集成了依赖管理：模块需要其他模块并按所需顺序加载。
- require 可以在任何地方调用：模块可以通过编程方式加载。
- 支持循环依赖。
缺点
- 同步API使其不适合某些用途（客户端）。
- 每个模块一个文件。
- 浏览器需要加载程序库或转换。
- 没有模块的构造函数（尽管Node支持这个）。
- 静态代码分析器很难分析。
Stage3： AMD
AMD诞生于一群对CommonJS采用的同步方式不满的开发人员。AMD和CommonJS之间的主要区别在于它支持异步模块加载。因为在浏览器的世界里，同步意味着阻塞。
AMD的核心在于通过使用JavaScript的传统闭包习惯来实现异步加载：在请求的模块加载完成时调用函数。
AMD加载程序可以在运行时获得给定项目的依赖关系图的完整画面。这对于浏览器尤为重要，因为启动时间对于良好的用户体验至关重要。
优点
- 异步加载（更好的启动时间）。
- 支持循环依赖。
- 兼容exports和require。
- 完全整合了依赖管理。
- 如有必要，可以将模块拆分为多个文件。
- 支持构造函数
这一点我还需要研究一下 - 插件支持（自定义加载步骤）。
缺点 - 语法稍微复杂一些（多一个define语法）。
- 除非已编译，否则需要加载程序库。
- 静态代码分析器很难去分析它。
Stage4： import和export 未来的新规范
import和export，静态编译器可以在编译时就构建完整的依赖树，而不需要在运行时读取依赖
关于import是同步还是异步，官网文档给了这样的答案，Support for both synchronous and asynchronous loading ，取决于引擎加载模块的方式是同步还是异步，服务器端是同步，浏览器端就是异步
优点
- 支持同步和异步加载。
- 语法简单。
- 支持静态分析工具。
- 集成在语言中（将来浏览器都支持这一边标准后，是不用像CMD和AMD那样还需要插件库去支持这一范式的）。
- 支持循环依赖。
缺点
- 暂时各大浏览器都无法原生支持。
东扯西扯
- CommonJS模块： 应用于服务端，同步加载，一个模块加载完了，才运行后面的代码，对服务器端来说这不是问题，因为数据储存在硬盘，基本就是读取的时间
- AMD范式：异步加载模块，当加载一个模块时，不阻塞后面的代码执行，而是设置了一个回调，当模块加载完成后，回调执行业务逻辑
- async和defer，都是异步加载，但是async下载完马上执行（且不保证顺序执行），defer要等到渲染后再执行（严格按照加载顺序执行）
- AMD是依赖前置，先执行依赖，CMD推崇依赖就近、延迟执行
- ES6和CommonJS不同点 ES6 模块与 CommonJS 模块的差异：
- import要放在文件顶部，require不用，import是编译时的，require是运行时的（runtime），import本质上会被编译成require
- CommonJS 模块输出的是一个值的拷贝，ES6 模块输出的是值的引用。
- CommonJS如果输出原始类型值，如果输出后，试图去改变这个值，那么不会被改变了
- CommonJS 模块是运行时加载，ES6 模块是编译时输出
- ES6在node和浏览器中的使用
- ES6首先被babel编译，然后如果是要跑在浏览器上，需要一些 bundler （ webpack ， browserify ）帮你处理依赖打包成能在浏览器跑的代码
- 所以我们的项目中写了ES6的import，但是不叫做在Node中使用了ES6，而是ES6语法被babel编译了Node中使用ES6的模块
- 浏览器中实现ES6的import 浏览器原生支持import
JavaScript Module Systems Showdown: CommonJS vs AMD vs ES2015JavaScript 模块的循环加载
模块化七日谈
