ES Modules: suggestions for improvement

[James Burke]

On Thu, Jun 28, 2012 at 7:56 AM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
> 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.

As Kevin says later, that is not what I asked for.

A developer using a module system does not want to have to manually
know that some dependencies need to be included as script tags before
starting loading. Often they are using modules that have dependencies,
that have dependencies, and they do not want to know that they have to
manually inspect the dependency tree to figure out what modules need
to be inlined as script tags before using modules themselves.

So, they will rely on a someone to provide a script loader library to
handle this. But that is what module support should do by default.
Otherwise, forms like AMD will continue to thrive, and worse yet cause
confusion in the minds of developers. There should be one module
format, usable with existing code as dependencies for es modules.

This is a real use case because it comes up all the time in AMD. Ask
any AMD+backbone user. Backbone does not use a module format, but it
is used all the time as a dependency in AMD modules.

This is why relying on "parse all the dependencies before eval for
exports" is a problem. My proposal of "eval dependencies, get those
exported values, then use that exported value to modify the AST of the
current module, then eval" approach in the other thread is an attempt
to solve that problem.

With that, you can support these older libraries that need to use the
runtime API so they can live in both worlds, but you still have a shot
at supporting things like import checking.

I think working this out in person or in online, real time may work
better. Sam or Dave, feel free to contact me offline if you want to do
so.

I will also try to set up a repo with some test scenarios, because the
optimization case when combining modules also needs more work.

James