ES modules: syntax import vs preprocessing cs plugins

Sam Tobin-Hochstadt samth at
Thu Jul 5 10:15:11 PDT 2012

On Wed, Jul 4, 2012 at 4:50 AM, Claus Reinke <claus.reinke at> wrote:
> I think there has been a disconnect in how you and I think about
> using the new module loaders. Since you're involved in the design,
> its probably my view that needs adjustment, but I'd appreciate if
> your view could be made clearer on the module loader page. At
> the moment, I do not have sufficient information to decide whether
> the proposed functionality will be sufficient in practice.
> To outline the disconnect, consider this simple static module
> chain for a dummy project ab I might like to use:
>    // a.js
>    export var a = "a";
>    // b.js
>    import {a} from 'a';
>    export var b = a+"b";
> To use this in my main code, I again use static import
>    // main.js (or perhaps a script element in index.html)
>    import {b} from 'b';    // early failure-protection here
>    .. other imports ..        // executed in sequence, but
>                                         // can be loaded in parallel
>    .. lots of code that uses imports ..
>                                        // if this code is part of a HTML
>                                        // source, we can use imports
>                                        // to fill static HTML syntax here
> Now, if I need to use module loader hooks while importing
> the ab project, I thought there would be a way to extend
> the default loader, then keep the rest of main.js unchanged.

In what way do you want to extend the default loader?  Some changes
don't require modifying `main.js` at all.  For example, we might have:

System.set('jquery', {...});
// main.js
import {b} from 'b';
import $ from 'jquery';

On the other hand, if you want to set up a new loader that translates
CoffeeScript to JS, then someone needs to invoke that new loader.

If you can give an example of what you want to change about the
default loader, then perhaps I can be more specific.

Both of your snipped examples are reasonable uses of the loader API.
Some of your problems with them seem to be general complains about
asynchrony, rather than issues with the module loading system.  For
example, making the module available outside the callback passed to
`.load` could involve promises, or `yield` with task.js, or something
else, but we can't just add synchronous loading.
sam th
samth at

More information about the es-discuss mailing list