[Note change of Subject:] On Mon, Dec 26, 2011 at 12:15 PM, Axel Rauschmayer <[email protected]> wrote:
> For another the modules infrastructure that you have on >> node is (for good reasons, I suspect) completely different to the >> infrastructure available on the client, which makes a difference to >> the way you structure your program. >> > > I’ve heard that claim many times, but I have yet to see compelling > evidence [1]. I find the competing module standards Common JS Modules > and Asynchronous Module Definitions (AMDs) to be very similar. Some argue > that AMDs are too complicated, but I don’t think they could be any simpler > (in their basic version). > Hi Axel, a nice demonstration of the simplicity of the core of AMD is the simplicity with which it can be implemented using a promise library. From < http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#amd_loader_lite >: function makeSimpleAMDLoader(fetch, moduleMap = Map()) { var loader; function rawLoad(id) { return Q(fetch(id)).when(function(src) { var result = Q.reject(new Error('"define" not called by: ' + id)); function define(deps, factory) { result = Q.all(...deps.map(loader)).when(function(imports) { return factory(...imports); }); } define.amd = {lite: true}; Function('define', src)(define); return result; }); } return loader = Q.memoize(rawLoad, moduleMap); } > Having two competing module standards hurts the JavaScript ecosystem, but > with ECMAScript.next modules that problem will hopefully soon be gone. > > AMD (Asynchronous Module Definition) as supported on the client by > require.js and curl.js is catching on for precisely that reason. There is > no shortage of adapters between AMD and CommonJS modules, so AMD modules > are also quite usable on the server. > > > The adapters are all a bit cumbersome to use. IMHO, the best option is > still boilerplate (to conditionally turn an AMD into a Node.js module): > > ({ define: typeof define === "function" > ? define > : function(A,F) { module.exports = F.apply(null, A.map(require)) } }). > define([ "./module1", "./module2" ], > function (module1, module2) { > return ... > } > ); > > > [1] http://www.2ality.com/2011/11/module-gap.html > I like this adapter, and have just changed < http://code.google.com/p/es-lab/source/browse/trunk/src/ses/amdTest3.js> to test that it works with our simple AMD Loader in translation-free SES-on-ES5 (similar to the above, at < http://code.google.com/p/es-lab/source/browse/trunk/src/ses/makeSimpleAMDLoader.js>). You can run this test by visiting < http://es-lab.googlecode.com/svn/trunk/src/ses/explicit.html> in a modern browser. If you see the line "AMD loader test...succeeded", then it did. However, I am confused by the "module.exports = ..." part of your boilerplate. The main CommonJS wiki seems down at the moment, but looking at <http://wiki.commonjs.org.mirrors.page.ca/articles/m/o/d/Modules.html> on the mirror site, I could not find any support for this idiom. The closest I could find was < http://wiki.commonjs.org.mirrors.page.ca/articles/m/o/d/Modules_SetExports_9215.html>, which suggests it should read "module.setExports(...);" instead. Where does "module.exports = ..." come from? -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
