The overall goal for the Asynchronous Module Definition (AMD) format is to provide a solution for modular JavaScript that developers can use today. It was born out of Dojo’s real world experience using XHR+eval, and proponents of this format wanted to avoid any future solutions suffering from the weaknesses of those in the past.
The AMD module format itself is a proposal for defining modules in which both the module and dependencies can be asynchronously loaded. It has a number of distinct advantages, including being both asynchronous and highly flexible by nature, which removes the tight coupling one might commonly find between code and module identity. Many developers enjoy using it, and one could consider it a reliable stepping stone toward the module system proposed for ES Harmony.
AMD began as a draft specification for a module format on the CommonJS list, but as it wasn’t able to reach full consensus, further development of the format moved to the amdjs group.
Today, it’s embraced by projects including Dojo, MooTools, Firebug, and even jQuery . Although the term CommonJS AMD format has been seen in the wild on occasion, it’s best to refer to it as just AMD or Async Module support, as not all participants on the CommonJS list wished to pursue it.
There was a time when the proposal was referred to as Modules Transport/C, however as the spec wasn’t geared toward transporting existing CommonJS modules, but rather—for defining modules—it made more sense to opt for the AMD naming convention.
The first two concepts worth noting about AMD are the idea of a define method for facilitating module definition and a require method for handling dependency loading. define is used to define named or unnamed modules based using the following signature:
define( module_id /*optional*/, [dependencies] /*optional*/, definition function /*function for instantiating the module or object*/ );
原文：https://www.cnblogs.com/chucklu/p/11081285.html