前端模块化的发展史

原文参考 玉伯 大神些的，我整理了一下。

 

我们今天主题说下前端模块化发展的历史，主要就是针对AMD CMD 的发展，这两个东西是一种规范，他们实际产物是 AMD是RequireJS，CMD的产物是seajs，他们的出现都是在COMMONjs基础上发展而来的，那我们得先说说COMMONjs。

 

COMMONJS

大概 09 年 – 10 年期间，CommonJS 社区大牛云集。CommonJS 原来叫 ServerJS，推出 Modules/1.0 规范后，在Node.js 环境下取得了很不错的实践。09年下半年这帮牛逼爱折腾的大神们想把 ServerJS 的成功经验进一步推广到浏览器端，因而将社区更名叫 CommonJS，同时激烈争论 Modules 的下一版规范。分歧和冲突由此诞生，逐步造成了三大流派：Modules/1.x （彻底基于1.0的功能，只是增长一个转换功能），Modules/Async ，Modules/2.0 。

Modules/1.x 流派：这个观点以为 1.x 规范已经够用，只要移植到浏览器端就好。要作的是新增 Modules/Transport 规范，即在浏览器上运行前，先经过转换工具将模块转换为符合 Transport 规范的代码。如今值得关注的有两个实现：component 和es6 module。

Modules/Async 流派：这个观点以为浏览器有自身的特征，不该该直接用 Modules/1.x 规范。这个观点下的典型表明是 AMD 规范及其实现 RequireJS。这个稍后再细说。

Modules/2.0 流派：这个观点以为浏览器有自身的特征，不该该直接用 Modules/1.x 规范，但应该尽量与 Modules/1.x 规范保持一致。这个观点下的典型表明是 BravoJS 和 FlyScript 的做者。BravoJS 做者对 CommonJS 的社区的贡献很大。FlyScript 的做者提出了 Modules/Wrappings 规范，这规范是 CMD 规范的前身。惋惜的是 BravoJS 太学院派，FlyScript 后来作了自我阉割，将整个网站（flyscript.org）下线了。这个故事有点悲壮，就不细讲了。

上面是产生的三大流派，也就是说Modules/2.0开始的产物都无疾而终了 ，而当时Modules/1.x 规范的 ES6还不成熟，在后来就是以Modules/Async 为规范的 RequireJS 发展的很火热。

可是AMD 的RequireJS 的 执行时机有异议，模块书写风格有争议，一直没有被CommonJS社区认同，我们详细的说下这两个点：

AMD 里提早下载 a.js 是浏览器的限制，没办法作到同步下载，这个社区都承认，但执行，AMD 里是 提早执行，二在基础Modules/1.0 规范里是第一次 require的时候才执行。这个差别不少人不能接受，包括持有Modules/2.0 观点的人也不能接受AMD的这个观点，这个差别，也致使实质上 Node 的模块与 AMD 模块是没法共享的，存在潜在冲突；

另一个就是：模块书写风格有争议

AMD 风格下，经过参数传入依赖模块，破坏了 就近声明 原则，就近原则就是在用的时候才会用，而不须要提早声明模块。最后，AMD 从 CommonJS 社区独立了出去，单独成为了 AMD 社区，后来大家就知道了 RequireJS 特别火!

其实这个时候 脱离了 CommonJS 社区的 AMD 规范，实质上演化成了 RequireJS 的附属品，后来RequireJS 社区有不少人反馈想用 require 的方式，最后 RequireJS 做者妥协，才有了这个半残的支持。（注意这个是伪支持，背后依旧是 AMD 的运行逻辑，好比提早执行）AMD 的流行，很大程度上取决于 RequireJS 做者的推广，AMD 规范的演进，离不开 RequireJS。

 

Modules/2.0

BravoJS 的做者 Wes Garland 有很深厚的程序功底，在 CommonJS 社区也很是受人尊敬。但 BravoJS 自己很是学院派，是为了论证 Modules/2.0-draft 规范而写的一个项目。学院派在实用派的 RequireJS 面前不堪一击，如今基本上只留存了一些美好的回忆。

这时，Modules/2.0 阵营也有一个实战派：FlyScript，提出了很是简洁的Modules/Wrappings 规范：这个简洁的规范考虑了浏览器的特殊性，同时也尽量兼容了 Modules/1.0 规范。悲催的是，FlyScript 在推出正式版和官网以后，RequireJS 当时正直红火。期间 FlyScript 做者 和 RequireJS 做者 James Burke 有过一些争论。再后来，FlyScript 做者作了自我阉割，将 GitHub 上的项目和官网都清空了，官网上当时留了一句话，模糊中记得是：我会回来的，带着更好的东西。 

这中间究竟发生了什么，不得而知。后来玉伯发邮件给 FlyScript做者 询问，对方给了两点挺让我尊重的理由，大意是：

1. 我并不是前端出身，RequireJS 的做者 James Burke 比我更懂浏览器。
2. 咱们应该协同起来推进一个社区的发展，即使它不是你喜欢的。

 

这两句话对玉伯影响很大。也是那以后，开始仔细研究 RequireJS，并经过邮件等方式给 RequireJS 提出过很多建议。再后来，在实际使用 RequireJS 的过程当中，遇到了不少坑。那时 RequireJS 虽然很火，但真不够完善。期间也在寻思着 FlyScript 离开时的那句话：“我会回来的，带着更好的东西”

玉伯说我没 FlyScript 的做者那么伟大，在不断给 RequireJS 提建议，但不断不被采纳后，开始萌生了本身写一个 loader 的念头。

这就是 SeaJS。SeaJS 借鉴了 RequireJS 的很多东西，好比将 FlyScript 中的 module.declare 更名为 define 等。SeaJS 更多地来自 Modules/2.0 的观点，但尽量去掉了学院派的东西，加入了很多实战派的理念。这个就是CMD的间接产物，SeaJs。

 

好了基本的历史都说完了，不知道我说的能不能让你们听明白，大概的总结下就是 最早有的COMMONJS，由于COMMONJS用因而服务端的，不能直接用于浏览器，对于怎样将这个规范用在浏览器，新生事物必然有争论，也的就产生了不一样的观念和论点，因此也就出现了适用于浏览器的AMD规范，CMD规范，AMD的存在的一些问题不被COMMONJS社区认同，最后独立运做，固然RequireJS也确实也大火了一段时间，后来CMD的产物seajs被玉伯开发出来。

到如今来看这两个产物估计是已通过时了，固然还有在用的，毕竟后来的webpack es6的发展势不可挡，webpakc对三种规范彻底支持，后面的时间还会给你们分享下webpack的一些知识，对于前端模块化发展历史就说到这里，对于初学前端的人了解历史发展仍是颇有必要的。其实这原文是玉伯写的，我只是更改了下变成了我本身的化，方便你们理解，你们也能够去搜下关于前端模块化历史那点事，这里没有说为何须要模块化 你们也能够先了解下，带着问题去学习才会学的更快。

 

好，今天就到这里，哪里说的不对请指正，有问题能够留言，谢谢，下次见！