Module loader use for optimizers (was Re: ES modules: syntax import vs preprocessing cs plugins)

James Burke jrburke at gmail.com
Wed Jul 4 11:30:16 PDT 2012


On Tue, Jul 3, 2012 at 4:27 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
> On Tue, Jul 3, 2012 at 7:19 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>> Sam,
>> Isn't it also the case that the full characteristics of the default module loader used by browsers still remain to be specified?  This might be somewhat out of scope for TC39 put practically speaking it's something we will need (and want) to be involved with.
>
> Yes, this needs to be fully specified, but Dave and I have thought a
> bunch about this particular issue, and I think the issues here are
> better understood, because they're similar to other ES/HTML
> integration issues.  As an example, where the system loader looks for
> JS source specified with a relative path should be related to how the
> browser does this for script tags.

Along those lines, I would like to see how the resolution logic that
is used for browsers could be used for optimizers that combine modules
together into scripts for performance reasons.

Those optimizers normally run in a non-browser environment, so
figuring out how an optimizer that runs in those other environments
can know the browser rules.

Maybe it means the optimizers need to hand code the rules themselves
and handle the parsing of module syntax themselves.

In my ideal world though, the ES module specs come with default
resolution logic that works best for browsers (but allows overrides)
and a Loader could be used in some kind of "trace mode", to get the
dependency graph without executing the modules. This would help
eliminate cross browser and cross-tooling bugs.

James


More information about the es-discuss mailing list