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

Sam Tobin-Hochstadt samth at ccs.neu.edu
Thu Jul 5 11:40:01 PDT 2012


On Wed, Jul 4, 2012 at 2:30 PM, James Burke <jrburke at gmail.com> wrote:
> 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.

I think optimizers will need to parse module syntax, just like they
parse all the rest of the syntax of JS.  For the default browser
resolution rules, those certainly need to be specified.

> In my ideal world though, the ES module specs come with default
> resolution logic that works best for browsers (but allows overrides)

In the ES spec, we can't build in too much that's browser specific,
but perhaps an Annex is the right place for this.

> 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.

A 'trace mode' sounds like a very useful tool, for this and other
things besides.  I've definitely appreciated similar tools in other
languages.
-- 
sam th
samth at ccs.neu.edu


More information about the es-discuss mailing list