Alternative proposal to privateName.public

Axel Rauschmayer axel at rauschma.de
Mon Dec 26 12:15:20 PST 2011


>  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
axel at rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111226/c2971923/attachment.html>


More information about the es-discuss mailing list