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

Mark S. Miller erights at google.com
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 rauschma.de> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111226/d7765255/attachment-0001.html>


More information about the es-discuss mailing list