AMD 为浏览器端开发带来了诸多好处：模块声明、异步加载、依赖管理、bundle等，已经成为很多团队应用开发的标配。在正确的代码下，一切看起来都还好，但是当问题出现时，追查过程通常会令人头疼，此时Loader的提示信息对错误的追查非常关键。ESL 是熊厂应用得比较多的 AMD Loader，本篇blog试图对 ESL 的错误场景与信息提示策略，以及如何追查错误，进行简单的介绍。主要涉及以下3个方面：
先厚脸皮求关注。
首先，建议大家在开发中追查错误时，使用 chrome 浏览器的开发者工具。因为它对 re-throw 错误的 stack 跟踪与查看支持得比较好。
阅读全部ESL 是一个浏览器端、符合AMD的标准加载器，适合用于现代Web浏览器端应用的入口与模块管理。
通过右键另存的方式可以下载ESL:
今天，ESL release 了 2.0.4。到这里本应该完了，不过好像内容少了点。为了凑数，还是多扯几句吧：
阅读全部理由很简单，因为太大了。RequireJS 经过语法压缩和 GZip 后，体积超过了 6k。RequireJS 最新版本已经降到了 6.1k，在 2012 年底时候的版本是接近 7k。由于下面的一些期望，让我们觉得这个体积比较大：
既然这个体积比较大，那多少合适呢。当时我们拍了脑袋，一个 Loader，各种流转与依赖处理，两种 require，URL 查询，再加上异步的插件机制，就算看起来比较复杂，GZip 后 3k 应该没问题。开发时间我们规划了一个月，主要还是为编写测试用例留出一些时间。
后来...后来，事情远远超出了想象。我们开发了 AMD Loader: ESL，包括前前后后的一些改进和 new feature，开发过程持续了一年半多。现在虽然是一个特性稳定版本，但是仍未结束，可预见的未来还有 shim 的支持需要添加。至于体积，我们也没控制住，在每个我们觉得无法或缺的 feature 中，它的体积最终是 3.4k。如果你觉得所有的错误信息你都不需要，那么可以选择 min 版本，体积是 3.1k，超过最初的梦想并不太多。可见男人的承诺多半不靠谱。
在 设计思路 篇中，已经对 AMD 在设计上的一些考虑做了比较详细的论述。所以这一篇只会提一些建议，引用一些 设计思路 篇中的结论，不会再详细描述为什么。
本篇提出的所有建议，都是针对于开发时就使用 AMD 的玩法。据我所知，有一些团队在开发时按照 CommonJS 的方式编写模块，通过开发时工具监听文件变化实时编译，上线前通过工具构建，AMD 纯粹被当作模块包装来用。本篇提出的建议不涵盖这种应用场景。
部分建议有一定的重叠，或者理由是相同的。举一反三能力较强的阅读者可能会觉得我很罗嗦，见谅。
阅读全部AMD 的全称是 Asynchronous Module Definition。顾名思义，这是一种定义模块的方式，并且是异步的。在其 Spec 的第一段描述中，就强调了特别适合浏览器环境。
The Asynchronous Module Definition (AMD) API specifies a mechanism for defining modules such that the module and its dependencies can be asynchronously loaded. This is particularly well suited for the browser environment where synchronous loading of modules incurs performance, usability, debugging, and cross-domain access problems.
我觉得，AMD 适合浏览器环境开发的主要特性有下面几点：
我们决定全面使用 AMD 进行前端开发，到现在已经两年的时间了。最初做这样的选择很简单，国外已经有很多使用 AMD 的成功例子了，大多数主流的 Libraries 和 Frameworks 对 AMD 也都有很好的支持，并且 AMD 的模块异步加载也为按需加载优化从根源上提供了支持。而我们也不想自己生产标准。所以我们在2012年的时候，经过一两次简单的讨论，就这么愉快的决定了。
两年过去。在实践的过程中，我们充分感受到了 AMD 的好处，不禁感叹其完备的设计思路和考虑。另外，我们也感觉到 AMD 在前端开发中的门槛还是不低的。主要体现在新同学入门的时间比较长，老同学很多也没有真正理解 AMD ，在项目中还是会用出一些不太符合常识的玩法。刚好最近空出一些时间，就写写一些我理解的 AMD ，给在玩 AMD 的同学一些参考，也给自己一个交代，以后就不用每个同学讲一遍了。
在这个时间节点，写 AMD 是需要一定的勇气的。作为一个不太成熟的领域，前端技术的发展一直很快，以致于一个东西如果一段时间没有变化没有发出新的声音，就会被认为过时过气。我也经常听到大家更愿意谈论AngularJS、React、ES6、Mobile。在这样的技术环境下，写一个“过气”的 AMD 其实是很难找到什么共鸣的。但我一直崇尚 精工，这需要态度、坚持以及时间的沉淀，我觉得我们在 AMD 的实践上做的还算及格，就选了这个话题。
本着既然要写就写多点的原则，我打算从 设计思路 和 应用实践 两个方面来写，顺便取了个title： Dissecting AMD。刚好我们有实现一个 AMD 的 Loader：ESL，所以顺便写一章 Loader实现，打打广告。