I have been reading about how the dojo 1.7 loader uses an AMD API/framework here and here too, and I came across this quote on one of the slides: "AMD(’s) greatest benefit isn’t being able to load scripts on-demand, as some people may think, the greatest benefit is the increase of the code organization/modularity and also the reduced need for globals/namespacing." But my question is, can't global variables already be avoided by using normal js functions, and maybe dojo.hitch() if you need to access another function's execution context (and another function's 'private' variables)? Put another way, other than asynchronously loading only what you need, what is the benefit of the AMD framework?
I have been reading about how the dojo 1.7 loader uses an AMD API/framework here and here too, and I came across this quote on one of the slides: "AMD(’s) greatest benefit isn’t being able to load scripts on-demand, as some people may think, the greatest benefit is the increase of the code organization/modularity and also the reduced need for globals/namespacing." But my question is, can't global variables already be avoided by using normal js functions, and maybe dojo.hitch() if you need to access another function's execution context (and another function's 'private' variables)? Put another way, other than asynchronously loading only what you need, what is the benefit of the AMD framework?
Share Improve this question asked Feb 6, 2012 at 17:26 TedTed 1,6908 gold badges31 silver badges52 bronze badges1 Answer
Reset to default 9The benefits of AMD are the benefits of having a module system, analogous to a namespace system in other languages. In JavaScript, we often faked this with global variables, but modules give a number of specific benefits:
These modules are offered privacy of their top scope, facility for importing singleton objects from other modules, and exporting their own API.
--- From the CommonJS Modules/1.1.1 spec, which started it all.
Key here is the import and export facilities. Previously everyone was doing this ad-hoc, with globals (like window.jQuery
, window._
, etc.). To get at jQuery's exported functionality, you had to know the magic name, hope nobody conflicted with it, and be sure that the jQuery script was loaded before your script. There was no way of declaratively specifying your dependency on jQuery, and jQuery had no way of saying "this is what I export" apart from just stuffing them onto a global window.jQuery
object.
A module format fixes this: each module exports specific functions, e.g.
// math.js
define(function (require, exports, module) {
exports.add = function (a, b) { return a + b; };
});
and each module can require specific other modules, e.g.
// perimeter.js
define(function (require, exports, module) {
var math = require("math");
exports.square = function (side) {
return math.add(math.add(side, side), math.add(side, side));
};
});
On why AMD should be the module system of choice, James Burke, the author of RequireJS---an AMD loader much like Dojo has---wrote a blog post detailing why he thinks AMD is the best.