JS 的模块化编程（五）- AMD vs. CMD
更新日期:
本系列博客更像是读blog读文档的笔记，从诸多资料中梳理出了自己的认识。
JS 的模块化编程（一）- 模块的基本写法
JS 的模块化编程（二）- CommonJS
JS 的模块化编程（三）- AMD
JS 的模块化编程（四）- CMD
JS 的模块化编程（五）- AMD 和 CMD 的区别
JS 的模块化编程（六）- requireJS
AMD 和 CMD 的区别
- AMD 提前执行依赖 - 尽早执行，requireJS 是它的实现
- CMD 按需执行依赖 - 懒执行，seaJS 是它的实现
言论1
玉伯说： “
AMD 是 RequireJS 在推广过程中对模块定义的规范化产出。
CMD 是 SeaJS 在推广过程中对模块定义的规范化产出。
类似的还有 CommonJS Modules/2.0 规范，是 BravoJS 在推广过程中对模块定义的规范化产出。
还有不少…”
这些规范都是为了JS的模块化开发，特别是在浏览器端。
言论2
屈屈说： “
AMD 运行时核心思想是「Early Executing」，也就是提前执行依赖。这个好理解。
CMD 按需执行依赖可以避免浪费，但是带来更长的等待时间。
SeaJS 对模块的态度是懒执行, 而 RequireJS 对模块的态度是预执行。
我觉得「尽早执行」或「按需执行」两种策略没有明显的优劣之分，但 AMD 这种「模仿别人写法，却提供不一样的特性」这个做法十分愚蠢。这年头，做自己最重要！
因为 CommonJS Wrapper 并不会改变 AMD「尽早执行」依赖的本质！
”
言论3
至此可以对由 commonJS 衍生出来的方案做出总结了。在浏览器端来设计模块加载机制，需要考虑依赖的问题。我们先把依赖分为两种：
- “强依赖” —— 肯定需要
- “弱依赖” —— 可能需要
对于强依赖
如果要性能优先，则考虑参照依赖前置的思想设计你的模块加载器，我个人也更推崇这个方案一些；
如果考虑开发成本优先，则考虑按照依赖就近的思想设计你的模块加载器。
对于弱依赖
只需要将弱依赖的部分改写到回调函数内即可。
如果现在我要实现一个模块加载器，我会将强依赖前置，弱依赖采用异步回调函数的形式，其它的方法我认为都只是语法糖而已，仅此就够了。
其他言论
- 建议取消使用 CMD 这个名称，统一使用 CommonJS 规范称谓
- AMD 代码是 requirejs，CMD 则是 seajs
- 加载模块时：AMD 提前加载，依赖前置；CMD 延迟加载，依赖就近。
- 正如玉伯所说：RequireJS 和 Sea.js 都是模块加载器，倡导模块化开发理念，核心价值是让 JavaScript 的模块化开发变得简单自然。
- 根据我大量的阅读文档，在遵循一定的写法，感觉这两个都能实现一样的功能。只是作者在推广其思想要如何如何。
碎碎念
果然 AMD 和 CMD 的讨论很是激烈。之前 75团 的分享上有一次，某人的开场是这样的“今天，我们不讨论 AMD 好还是 CMD 好。今天我们只分享在图搜中的JS模块化应用”。
有时候吧，会觉得，之所以争的如此激烈，是因为有些人只用过了a，且用a的思路去试着用b，结果踩了好多坑（或者这根本就不是坑-而是没用对）又或者是抱着去验证而不是去学习的心态去用，结果可想而知。又或许有一些只用了个皮毛的入门人士，就来网上装作很有经验的样子去大肆批判这个，表扬那个，于是整个空气便浑浊了。看似硝烟弥漫的严肃紧张，实则是背后杂乱无章的瞎嚷嚷。
我个人觉得，对待技术本身：能解决碰到的问题就ok了。至于哪个好哪个不好，没必要争论个你死我活。要讨论就讨论每个的优缺点就可以了，优缺点其实也就是应用场景了。而且，优缺点是可以变的，语言也是在不断根据程序员的需求慢慢变化的….但针锋相对地吵架，就没啥实际意义了，最多是技术圈里的挑话题，炒作 or 刷存在感？
若要真的讨论两者的好坏，那就先做做功课。【自己也在做功课中，于是自己的看法暂且保留】
1.去看源码。。。理解真正的思想是什么？原理是什么？
2.写出符合规范的代码，去浏览器&实际项目中测试性能。。。
3.依据正确的场景去正确的用东西。。
理论和实战相结合后，且有个结论了之后，再来清清楚楚明明白白的争辩。
参考
http://www.zhihu.com/question/20351507
http://www.zhihu.com/question/21347409#answer-2323656
http://www.zhihu.com/question/20342350
http://www.douban.com/note/283566440/
https://www.imququ.com/post/amd-simplified-commonjs-wrapping.html