Initializing workers

[bathos]

The “open questions” section asks:

Can we make this work with existing web APIs that expect whole source files, such as new Worker() or CSS.paintWorklet.load()?

I would really like to see that happen. There are contexts where you:

• have a script/worker pair that behave as one logical module (in particular an issue in npm libs, since require is useless; there’s no standard way to declare the relationship or ensure the worker ends up served properly at some expected URL)
• have a dynamically generated worker, which means adding a blob: scheme allowance to your CSP — not a big deal if the agent supports worker-src, but if the agent doesn’t this would be a script-src allowance, which effectively opens the full eval gates

In the second case, blöcks would additionally provide the benefit of being "actual code", rather than the blob being a stitched together, opaque string.

[domenic]

Blöcks would not be usable for your second case, since they are static source text.

I don't really understand the URL-related issues of your first case. (For a few reasons, e.g.: require isn't part of the JS language and fixing its deficiencies isn't our responsibility; workers live at URLs already and so there shouldn't be a problem ensuring they're served at specific URLs; ...) But I agree with the idea that it's nice to have worker code in one source file.

I'm not sure we need to make that work with the old, heavyweight Worker constructor, where it's kind of a plus that you have to go through the arduous process of creating a separate script file if you're planning to consume an entire thread. But at least for newer features like worklets, which are not as heavyweight, blöck syntax probably makes sense.

Note that this is mostly an issue for the web side of this proposal, unrelated to the JS syntax side being worked on here. The one thing it might affect is what syntactic goal the inside of the {| ... |}s is allowed to have, e.g. for worklets, we would need the module goal instead of the async function body goal.

[bathos]

I think I described that pretty poorly, sorry. Require isn’t specifically significant: what I meant is that Workers are a wrinkle that can’t work the same way as other dependencies in libraries, so authors resort to stuff like inlining the worker source as blob or data URIs, which can have security implications. It’s possible that this proposal doesn’t provide a solution for this, but it seemed like it might be able to be part of a solution.

(Regarding the second case, I think they would often be useful because variable capture would provide a cleaner alternative solution for those needs most of the time. That is, they could more easily be refactored to be static, too.)