What about web workers?

[domenic]

It'd be very useful for web workers to be able to use module syntax and get all of the benefits thereof. This would I believe replace the annoying importScript global they use.

At first glance I think you'd need some kind of WorkerModule constructor to allow opt-in to these semantics. Or perhaps you could extend System with some kind of System.work("worker-module-id").then(() => ...)? That sounds nice.

[DavidBruant]

It'd be very useful for web workers to be able to use module syntax and get all of the benefits thereof.

Not sure I understand this. A Web Worker is an ECMAScript environment (and should follow JS engine improvements), so everything should work out of the box, no?

[domenic]

Well, is it a script, or is it a module? As is, everything in browsers is a script. Thus this repo, to discuss introducing modules.

[DavidBruant]

Say I write a worker.js file:

import f from "path/to/module/f";

window.addEventListener('message', e => {
    f(e.data);
})

(I'm completely out of date when it comes to module syntax, but this is irrelevant to this discussion)

And I create a worker in the main context:

var w = new WebWorker('worker.js')

I expect the worker to be initialized with the above script and work as expected (fetch modules depended on, etc.). I'm not sure I understand your question, but I hope what I have in mind is more clear.

[domenic]

I'd expect the worker to be run as a script, not a module, because right now browsers execute workers as scripts, just like they do <script src>s. So import's appearance would be a syntax error, according to current specs. Remember that scripts and modules have different top-level syntaxes.

As another example, consider a worker which does foo = "bar" (no var). Since workers are executed as (sloppy) scripts right now, this would create a global property foo. Whereas if they were executed as modules, they would be in strict mode by default, so that code would throw an error.

[matthewp]

Great points, what would break if we just said workers are now modules?

[arv]

@matthewp Modules are strict and Script is sloppy. Top level variables in Script become globals, that is not the case for Module. We need an opt in :'(

[matthewp]

@arv Thanks, that makes sense then.

[matthewp]

To bring this one back up, how about a module mode?

"use module";

Is this an acceptable opt-in @arv @domenic ?

So there would be 3 ways to execute a module:

<module>
import f from "path/to/f.js";
</module>

<script>
"use module";

import f from "path/to/f.js";
</script>

// worker.js
"use module";

import f from "path/to/f.js";

[domenic]

No, this is not acceptable. Modes are not ergonomic and require language support (see all the spec text supporting use strict), which was explicitly decided against in designing ES2015.

[matthewp]

You're right, it's not very ergonomic. This is going to be a tough one as modules become the expectation. A different Worker constructor as you first suggested is one idea, but how does that play with constructors that inherit from Worker, such as ServiceWorker, they would need another form for modules as well. I'm going to think about this some more, thanks for the reply.