<script> type attribute and WorkerOptions dict type are a little overloaded now

[dandclark]

<script>'s type attribute is a little odd with this change.
<script type="module"> means a JavaScript module, while <script type="webassembly"> also means a module, but a different type of module. This is not super intuitive, but I don't really see a backwards-compatible workaround. I guess this can be justified by saying that there is no such thing as a 'classic' WebAssembly script (is that right?) so the distinction is clear in context.

Same thing with Workers; https://github.com/littledan/proposal-module-attributes#worker-instantiation conflicts a bit with the current way that the worker options dict is used to decide whether a Worker should be classic or module: https://html.spec.whatwg.org/multipage/workers.html#worker-processing-model

const worker = new Worker('resource.json', {type:'module'});

or

const worker = new Worker('resource.json', {type:'classic'});

Now we would also have

const worker = new Worker('resource.json', {type:'webassembly'});

Which is a little confusing because it is also a module, just not a JS one.

I don't see a good way to address this as changing <script type="module"> is obviously a non-starter. I thought I'd make a note of the issue though, as this is likely a criticism that we'll have to speak to.

[littledan]

Yes, I was thinking of using a secondary label, but I thought the overload was a good trade-off since those don't have many possible values anyway. Note that #7 points to more possible overloading.

[bmeck]

@littledan the web has few values, but that is not necessarily true of other environments. Deno has typescript, node loaders allow arbitrary formats, etc.

[littledan]

@bmeck Maybe you meant to post that on #8 or #10?

[bmeck]

@littledan it was in direct reply to:

since those don't have many possible values anyway

This isn't necessarily true in other environments especially with Worker APIs.

[littledan]

Cross-references would be useful here.

[bmeck]

• Node Loaders supporting arbitrary types: Feature: Importing non-JavaScript files nodejs/modules#115 , loader design work is ongoing but this is a first class feature
• Workers
  • in Node: https://nodejs.org/dist/latest-v13.x/docs/api/worker_threads.html
  • in Deno: https://github.com/denoland/deno/pull/1993/files (no docs?, changes show loading typescript)

[littledan]

Reviewing these, I'm having trouble finding any currently shipping feature that would lead to compatibility/interoperability issues with using a { type: ... } option as a parameter to initialize workers. Am I missing something?

[bmeck]

@littledan currently workers and node's main entrypoint (idk who does that currently) can load WASM via using type:module. I'm stating that the naming collision here doesn't make sense to try and overload.

[littledan]

Right, so, I was suggesting that we could join a namespace that has just a few entries, and work through the collisions. (And I imagine that, if you're talking about Node, you mean an experimental flag.) It still seems to me like that's a possible path.

But I'm also open to passing these options in a separate place. For example, the API for workers on the Web could be:

const worker = new Worker('resource.json', {with: {type:'webassembly'}});

[littledan]

I'm leaning towards using the syntax described above:

const worker = new Worker('resource.json', {with: {type:'webassembly'}});

This avoids all risk of namespace collisions. It's also used in import().

Also, for HTML tags, the withtype attribute would be used:

<script src="foo.wasm" type="module" withtype="webassembly"></script>

This is all checked into master.

I think these host integration things are something that we should work out by Stage 3.

[littledan]

I'm closing this issue, as the overloading has been removed.