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

From: "Matthew A. Miller" <[email-masked]>
Date: Wed, 16 Aug 2017 22:03:25 -0600

Hello DISPATCH,

The ECMAScript/JavaScript media types are in need of some updates.
We've started an informational document[1] to address that.  There
hasn't been much mailing list discussion yet, but we are asking now
where to direct the work.

In consultation with the ART Directors, we ask this document be adopted
by DISPATCH as one of its simple administrative documents.

The document is <
https://datatracker.ietf.org/doc/draft-bfarias-javascript-mjs >.

Issues can be filed on the GitHub repository at <
https://github.com/bmeck/I-D/issues >.

Thank you,

-- 
- m&m

Matthew A. Miller

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Aug 2017 15:14:24 +1000

Hi Matt,

First, this seems fine, almost trivial.

This statement implies a problem of greater scope than what you are solving:

   It is not possible to fully determine if a Source Text of ECMAScript
   is meant to be parsed in the Module or Script grammar goals based
   upon content alone.

My initial reaction to this statement was: so why aren't we seeing a
request for a new media type?

You neglect to mention that uses of the module on the web do not
depend on additional distinguishing marks because they have the
type="module" attribute on script tags.

Nit: There Are So Many Proper Nouns In This Document.  Is that really necessary?

On 17 August 2017 at 14:03, Matthew A. Miller
<[email-masked]> wrote:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Bradley Meck <[email-masked]>
Date: Thu, 17 Aug 2017 05:03:05 -0500

Hiya!

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.

This is out of band information not based upon content. I did not think it
necessary. Should it be mentioned if it is not based upon message content
nor information in the media type fields? I think that this statement also
applies to some tools such as module bundlers as well that are using fields
in package.json files.

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

-Brad

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Aug 2017 21:38:36 +1000

On 17 August 2017 at 20:03, Bradley Meck <[email-masked]> wrote:
> 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.

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.

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.

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.

> ECMAScript specification. We could make stylistic changes though!

Consistency good >> Too Many Capitals Are Bad

(In other words, don't change on my account.)

---

From: Bradley Meck <[email-masked]>
Date: Thu, 17 Aug 2017 08:23:30 -0500

Replies inline.

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

> It

Certainly, I can do that in the next version.

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

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

> than importScript in workers, so you don't need explicit

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.