ES Modules: suggestions for improvement

[Sam Tobin-Hochstadt]

On Thu, Jun 28, 2012 at 10:40 AM, Kevin Smith <khs4473 at gmail.com> wrote:
>>    <script src="/assets/add_blaster.js">
>>    <script>
>>    module main {
>>      import go from "add_blaster";
>>      console.log(go(4,5));
>>    }
>>    </script>
>
>
> That's *not* what I'd call a "forward-compatible" solution since you still
> have to use the script tag prior to importing.  What's needed is a way to
> tell the loader that "add_blaster" can be fetched from
> "/assets/add_blaster.js".

What James asked for was a solution for how libraries such as jquery
or backbone could be implemented so that they work in both worlds,
which is what I provided.

> I believe that's what James is referring to: a declarative set of mappings
> that inform the loader where to fetch certain modules from.  Creating a
> custom loader which overrides the default loader's resolve behavior is going
> to be too much work for this simple use case.  That's the argument, anyway.
>  If it's not difficult, then I think we as a community need to see examples
> of how that would work.
>
> It seems that a better way to enable forward-compatibility would be to
> provide an imperative way to set the exports of the current module:
>
>     if (this.System)
>       System.setCurrentModuleExports({ ... }); // A shorter name, of course!
>
> The "forward-compatible" module is then relieved of the necessity of naming
> itself using some arbitrary module name (which would obviously pollute the
> global module namespace: not acceptable).
>
> Trying to keep this message short, but it seems to me that once we allow the
> possibility of custom loader behavior (even as simple as declaratively
> remapping URLs), then the arguments for static import/export start to fall
> apart.  In order to keep the supposed benefits of static analysis, our tools
> (i.e. IDE) are going to have to be aware of that custom loading behavior to
> continue to be useful.  And if modules are dynamically injected into the
> module namespace with System.set, then static analysis (and the
> typo-checking that is deemed so important) is completely "out-the-window".
>
> Does this indicate that the static analysis arguments are on shaky ground?

No, it doesn't.  It's important to distinguish between the code that
runs to set up an environment (such as the call to `System.set` in my
mail) and code that runs *in* that environment (such as the `import`
statement in my mail).  What is runtime for one of these is
compilation time for the other.
-- 
sam th
samth at ccs.neu.edu