> 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). 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 -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss