ES5 Module Systems (was: Alternative proposal to privateName.public)

Mark S. Miller erights at
Mon Dec 26 13:46:39 PST 2011

[Note change of Subject:]

On Mon, Dec 26, 2011 at 12:15 PM, Axel Rauschmayer <axel at> 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 <

   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( {
             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 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, } }).
>     define([ "./module1", "./module2" ],
>         function (module1, module2) {
>             return ...
>         }
>     );
> [1]

I like this adapter, and have just changed <> to
test that it works with our simple AMD Loader in translation-free
SES-on-ES5 (similar to the above, at <>).
can run this test by visiting <> 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 <>
on the mirror site, I could not find any support for this idiom. The
closest I could find was <>,
which suggests it should read "module.setExports(...);" instead. Where does
"module.exports = ..." come from?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list