ES Modules: suggestions for improvement

James Burke jrburke at
Wed Jun 27 16:11:47 PDT 2012

On Wed, Jun 27, 2012 at 2:21 PM, Sam Tobin-Hochstadt <samth at> wrote:
> On Wed, Jun 27, 2012 at 3:37 PM, James Burke <jrburke at> wrote:
>> On Wed, Jun 27, 2012 at 11:56 AM, Sam Tobin-Hochstadt <samth at> wrote:
>>> Then we can use the module like this:
>>>    System.load("add_blaster", function(ab) { return ab.go(4,5); })
>>> or, since we know that "add_blaster" is a local module:
>>>    let { go } = System.get("add_blaster");
>>>    go(9,10);
>>> or, if we put the call to `System.set` in the previous script tag, we
>>> can just do:
>>>    import go from "add_blaster";
>>>    go(2,2);
>>> At no point here did we have to write a module system.
>> This is not usually how we have found loading to be done in AMD.
>> 'add_blaster' is usually not loaded before that import call is first
>> seen. Call this module foo:
>>   import go from "add_blaster";
>> The developer asks for foo first. foo is loaded, and parsed.
>> 'add_blaster' is seen and then loaded and parsed (although not sure
>> how 'add_blaster' is converted to a path…):
>> add_blaster calls the runtime:
>>   System.set("add_blaster", { go : function(n,m) { return n + m; } });
>> What happens according to the current modules proposal?
> I'm not quite sure what you're asking.  If the question is: does
> importing "foo" automatically compile "add_blaster", then yes, that
> happens automatically.  You can think about that as doing something
> internal that's similar to `System.set`.  But that's all implicit.  If
> we are in a system like NPM, where "add_blaster" might map
> automatically to "add_blaster.js", we could have:
> foo.js:
>    import go from "add_blaster"
>    go(1,2)
> add_blaster.js:
>    export function go(n,m) { return n + m; };

I was using the original code for 'add_blaster', say as you say, it is
in add_blaster.js:

    System.set("add_blaster", { go : function(n,m) { return n + m; } });

My understanding that since add_blaster.js uses the runtime API and
not the export, the above code will not work unless I construct a
loader library that first loads and executes add_blaster.js before
foo.js is parsed.

The use case: scripts, like jquery/backbone/others that want to live
in a non-harmony and harmony world, I would expect that they could be
adapted to call the System.set() API, but not use the new syntax

I am under the impression that library developers do not want to
provide two different versions of their scripts, just to participate
in es modules, but rather use a runtime check to register as part of
one script that works in es harmony and non-harmony browsers.
Otherwise, it feels like a "2 javascripts" world.


More information about the es-discuss mailing list