> 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
