js module大战

JS本身是一个多才多艺的语言，一个可以用自己编译自己的自由度极高的语言。正因为这份自由，出现了天花乱坠的规范与框架们，其中最基础的一块便是Module。

来来来，baby们，做个小测试： CommonJS·AMD·CMD·UMD·ES6，这些模块规范，大家熟悉几个？

注意注意：本文乃笔者主观写出的欢快脱线认知，也许和真正的模块形成的历史有所区别。

一切的根源

JS是一个自由度极高的语言，即使没有模块的概念。也可以通过IIFE，new一个对象来实现类似与模块的概念。也可以实现可复用，作用域独立，易维护。这样散装的，无法维护各个模块之间依赖。在一个JS文件中，模块一多，也许就是修罗场。

Module的诞生

于是JS Module，一个令人又爱又恨的名词诞生了。JS本身设计上就没有模块的概念，之后为了让JS变成一个功能强大的语言，业界大佬们各显神通，定了一个名为CommonJS的规范，实现了一个名为模块的东西。可惜大多浏览器并不支持，只能用于nodejs，于是CommonJS开始分裂，变异了一个名为AMD规范的模块，可以用于浏览器端，而由于AMD与CommonJS规范相去甚远，于是AMD自立门户，并且推出了requireJS这个框架，用于实现并推广AMD规范。正因为AMD与CommonJS如此不同，且用于不同的环境，为了能够兼容两个平台，UMD应运而生，不过笔者认为仅仅是一个polyfill，以兼容两个平台。此时，CommonJS的拥护者认为，浏览端也可以实现CommonJS的规范，于是稍作改动，形成了CMD规范，并且推出了seajs这个框架。正在AMD与CMD打得火热的时候，ECMAScript6给JS本身定了一个模块加载的功能，ES6表示“你们也别争了，JS模块有原生的语法了”。

真正的规范

对于众多规范中，只有CommonJS和ES6 import/export是真正的规范，其余的是利用JS现有的支持的方法模拟出的环境，以实现各自的规范。

至于为什么说CommonJS和ES6 import/export是真正的规范呢？因为只有原生支持他们的语法，才能实现他们的规范。

对于CommonJS而言，运行环境中，必须有require和module.exports的支持，才能运行。这就是浏览器与CommonJS无缘的主要原因。

至于ES6，失去对import和export关键字的支持，便一切都是零。比如，nodejs就不支持import和export，明明nodejs支持其他的ES6语法，怎么就对import和export如此不友好，笔者认为nodejs是为了实现commonJS的规范，因此不能接受ES6的模块扰乱nodejs的模块规范。

所以说CommonJS和ES6的模块才是真正的规范。

关于CommonJS和ES6模块，笔者曾经写过一篇关于他们的文章，这里不多做赘述,移步至读懂CommonJS的模块加载。

有关浏览器实现CommonJS模块的原理

既然浏览器缺少CommonJS的两个关键字导致，模块不成立，那么就创建一个模块环境。使用define这个方法，将函数内部模拟成CommonJS的环境，提供require和module.export的方法。无论是seajs还是requirejs都是通过define模拟环境的办法，实现module的。