随着单页应用与富客户端的流行，不断增长的代码库也急需合理的代码分割与依赖管理的解决方案，这也就是我们在软件工程领域所熟悉的模块化（Modularity）。所谓模块化主要是解决代码分割、作用域隔离、模块之间的依赖管理以及发布到生产环境时的自动化打包与处理等多个方面。二十年间流行过的 JavaScript 模块化解决方案包括但不限于直接声明依赖（Directly Defined Dependences）、命名空间（Namespace Pattern）、模块模式（Module Pattern）、依赖分离定义（Detached Dependency Definitions）、沙盒（Sandbox）、依赖注入（Dependency Injection）、CommonJS、AMD、UMD、标签化模块（Labeled Modules）、YModules、ES 2015 Modules。
命名空间模式
命名空间模式始于 2002 年，顾名思义我们可以使用特殊的约定命名。譬如我们可以为某个模块内的变量统一添加 myApp_ 前缀，譬如 myApp_address，myApp_validateUser() 等等。同样，我们也可以将函数赋值给模块内的变量或者对象的属性，从而可以使得可以像 document.write() 这样在子命名空间下定义函数而避免冲突。
var MYAPP = {
foo: function(){},
bar: function(){}
}
MYAPP.foo();
依赖注入
Martin Fowler 于 2004 年提出了依赖注入（Dependency Injection）的概念，其主要用于 Java 中的组件内通信；以 Spring 为代表的一系列支持依赖注入与控制反转的框架将这种设计模式发扬光大，并且成为了 Java 服务端开发的标准模式之一。依赖注入的核心思想在于某个模块不需要手动地初始化某个依赖对象，而只需要声明该依赖并由外部框架自动实例化该对象实现并且传递到模块内。而五年之后的 2009 年 Misko Hevery 开始设计新的 JavaScript 框架，并且使用了依赖注入作为其组件间通信的核心机制。这个框架就是引领一时风骚，甚至于说是现代 Web 开发先驱之一的 Angular。Angular 允许我们定义模块，并且在显式地声明其依赖模块而由框架完成自动注入
// file greeting.js
angular.module('greeter', [])
.value('greeting', {
helloInLang: {
en: 'Hello world!',
es: '¡Hola mundo!',
ru: 'Привет мир!'
},
sayHello: function(lang) {
return this.helloInLang[lang];
}
});
// file app.js
angular.module('app', ['greeter'])
.controller('GreetingController', ['$scope', 'greeting', function($scope, greeting) {
$scope.phrase = greeting.sayHello('en');
}]);
CommonJS
CommonJS 内的模块规范成为了 Node.js 的标准实现规范，其基本语法为 var commonjs = require("./commonjs");
加载时执行是 CommonJS 模块的重要特性，即脚本代码在 require 的时候就会执行模块中的代码。这个特性在服务端是没问题的，但如果引入一个模块就要等待它执行完才能执行后面的代码，这在浏览器端就会有很大的问题了。因此出现了 AMD 规范，以支持浏览器环境。
AMD
就在 CommonJS 规范火热讨论的同时，很多开发者也关注于如何实现模块的异步加载。Web 应用的性能优化一直是前端工程实践中不可避免的问题，而模块的异步加载以及预加载等机制能有效地优化 Web 应用的加载速度。AMD是 “Asynchronous Module Definition” 的缩写，意思就是“异步模块定义”。它采用异步加载方式加载模块，模块的加载不影响它后面语句的运行。所有依赖这个模块的语句，都定义在一个回调函数中，等到加载完成之后，这个回调函数才会运行。最有代表性的实现则是requirejs。
AMD（Asynchronous Module Definition）
UMD
AMD 与 CommonJS 虽然师出同源，但还是分道扬镳，关注于代码异步加载与最小化入口模块的开发者将目光投注于 AMD；而随着 Node.js 以及 Browserify 的流行，越来越多的开发者也接受了 CommonJS 规范。令人扼腕叹息的是，符合 AMD 规范的模块并不能直接运行于实践了 CommonJS 模块规范的环境中，符合 CommonJS 规范的模块也不能由 AMD 进行异步加载，整个 JavaScript 生态圈貌似分崩离析。2011 年中，UMD，也就是 Universal Module Definition 规范正是为了弥合这种不一致性应运而出，其允许在环境中同时使用 AMD 与 CommonJS 规范。Q 算是 UMD 的首个规范实现，其能同时运行于浏览器环境（以脚本标签形式嵌入）与服务端的 Node.js 或者 Narwhal（CommonJS 模块）环境中；稍后，James 也为 Q 添加了对于 AMD 的支持。
ES2015 Modules
JavaScript 模块规范领域群雄逐鹿，各领风骚，作为 ECMAScript 标准的起草者 TC39 委员会自然也不能置身事外。不同于 CommonJS 和 AMD 的模块加载方案，ES6 在 JavaScript 语言层面上实现了模块功能。它的设计思想是，尽量的静态化，使得编译时就能确定模块的依赖关系。在遇到模块加载命令 import 时，不会去执行模块，而是只生成一个引用。等到真的需要用到时，再到模块里面去取值。这是和 CommonJS 模块规范的最大不同。
模块化开发在现代开发中已是必不可少的一部分，它大大提高了项目的可维护、可拓展和可协作性。通常，我们 在浏览器中使用 ES6 的模块化支持，在 Node 中使用 commonjs 的模块化支持。
分类:
es6: import / export
commonjs: require / module.exports / exports
amd: require / defined
require与import的区别
require支持 动态导入，import不支持，正在提案 (babel 下可支持)
require是 同步 导入，import属于 异步 导入
require是 值拷贝，导出值变化不会影响导入值；import指向 内存地址，导入值会随导出值而变化
