ES modules: syntax import vs preprocessing cs plugins

Sam Tobin-Hochstadt samth at ccs.neu.edu
Tue Jul 3 16:27:09 PDT 2012


On Tue, Jul 3, 2012 at 7:19 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>
> On Jul 3, 2012, at 3:36 PM, Sam Tobin-Hochstadt wrote:
>
>>> ...
>>
>> [problems snipped]
>>
>> There are two issues here.  One is what code evaluated in nested
>> loaders looks like.  That's entirely up to the loader, but it
>> certainly can use `import` and `export` and all of the other features
>> of the module system.  Those references are resolved by the loader
>> being used.
>>
>> The second question is how we specify a particular loader to use.
>> This is easy to do in JS code: `myLoader.load(url, callback)`.  If we
>> want convenient syntax for using this in a particular environment,
>> then that would require an extension to the environment, such as an
>> HTML declaration to use a particular loader for the rest of the page,
>> or for a particular script tag.  This is certainly doable, but
>> requires coordination outside of TC39.
>
> 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.
-- 
sam th
samth at ccs.neu.edu


More information about the es-discuss mailing list