Re: [dispatch] Dispatching Work on ECMAScript Media Types Updates

[Bradley Meck <[e-mail]>]

Replies inline.

On Thu, Aug 17, 2017 at 6:38 AM, Martin Thomson <[e-mail]>
wrote:

> On 17 August 2017 at 20:03, Bradley Meck <[e-mail]> wrote:
> >> My initial reaction to this statement was: so why aren't we seeing a
> > request for a new media type?
> >
> > This was discussed in a few different places, ultimately culminating in
> no
> > body wanting to take that route. You can read some info on that in the
> link
> > to the informative TC39 issue https://github.com/tc39/ecma262/issues/322.
> It
> > appears you might be more interested in the HTML side of things, which
> would
> > be that a new media type would not load with the specification they have
> > already started deploying ( there was an issue about this on HTML side in
> > https://github.com/whatwg/html/issues/558 ). Some discussion about a
> `mode`
> > parameter instead of media type is in an issue on this proposal
> > https://github.com/bmeck/I-D/issues/1#issuecomment-322545837 . That
> might be
> > the better route since it will work in web browsers.
>
> I'm not questioning the decision (though I appreciate the pointers,
> thanks), just pointing out that there is an obvious question arising
> from your introductory text.  You don't need to defend the decision,
> but you should answer that question by mentioning that link metadata
> (type=module) ensures that no one else asks the question.
>

Certainly, I can do that in the next version.


>
> The discussion (and outcome if I'm reading correctly) on #1 leading to
> mode= certainly seems sensible.  Please pick a default of mode=script
> and save us all headaches.
>

If and when we agree on this parameter, I think a default of mode=script
without usage restriction for .js is a good idea. A similar usage
restriction and default of mode=module on .mjs also seems reasonable.


> Question, mainly for my gratification: if I include a module in a
> <link rel=preload>, how do I signal that it's a module?  You can't use
> a type= attribute there, because that key is taken for something else
> (media type).  I know that browsers like doing things like pre-parsing
> in addition to preloading.
>

Interestingly code can be loaded as both Script and Module due to the
ambiguities in place in the grammars and HTML reusing the same MIME type.
This makes it difficult to know ahead of time which grammar is being used.
Pre-parsing work on top level parsing for non-ambiguous sources has been
talked about a few times, but I don't know if they are implemented.

A good example of this ambiguity is having a file only containing:

```
// example
console.log(this) // window in Script, undefined in Module
```

You can see this in practice by loading it in both grammars with 2
different script tags:

```
<script type="module" src="./example"></script>
<script src="./example"></script>
```

I have to assume that you just use native es6 modules keywords rather
> than importScript in workers, so you don't need explicit
> identification there.


There are 2 mechanisms for dealing with Modules that can be used here.

1. The `import(...)` meta function of ECMAScript (
https://github.com/tc39/proposal-dynamic-import ) will be available in both
grammars. Browsers intend to treat any javascript using import mechanisms
as a Module. This meta function is not currently landed in the
specification, but is in the process of doing so pending implementation and
deployment. Once it becomes available a worker can use `importScripts()` to
load something like the following:

```
// this file is to be loaded via importScripts, it is using the Script
grammar

// the following both are loaded as modules, and are loaded in parallel
import('./taskA');
import('./taskB');
```

2. You can declare the type of a Worker using a configuration option. See
https://html.spec.whatwg.org/multipage/workers.html#workertype for more
details.


> >> Nit: There Are So Many Proper Nouns In This Document.  Is that really
> >> necessary?
> >
> > I think this is in part a stylistic thing of my writing. I tend to avoid
> > pronouns and am capitalizing grammar productions in the same manner as
> the
> > ECMAScript specification. We could make stylistic changes though!
>
> Consistency good >> Too Many Capitals Are Bad
>
> (In other words, don't change on my account.)
>