Declarative WebWorker? #4786

fserb · 2019-07-18T13:56:24Z

This is not a full proposal yet, but I'd like to float the idea.

How do people feel about having a declarative WebWorker API by providing a new attribute to the script tag that makes the script load on a separate WebWorker? For example:

<script id='myid' worker src='myscript.js'></script>
<script id='other' worker>
//...
</script>

document.getElementById('myid').targetWorker.postMessage(...);

or maybe using a different type:

<script id='myid' src='myscript.js' type='text/javascript-worker'></script>
<script id='other' type='text/javascript-worker'>
//...
</script>

document.getElementById('myid').worker.postMessage(...);

I think this is much nicer and more descriptive than the current createObjectURL(new Blob(textContent)) approach to inline workers. It could boost and simplify usage of WebWorkers.

The text was updated successfully, but these errors were encountered:

annevk · 2019-07-18T14:06:15Z

So I'm sure this was discussed before as <script type=worker> (alongside type=module before that settled; potentially as <worker> and <module>) and there was general support because of the annoying pattern you mention, but unfortunately I cannot find that discussion. I think something like this makes sense.

fserb · 2019-07-18T14:45:20Z

with type=module, it means we would have to add type=worker and type=worker-module, I guess.
I tried to find the discussion but couldn't find it either.

annevk · 2019-07-18T14:50:31Z

Or maybe only allow module workers since non-modules are considered "classic".

domenic · 2019-07-18T15:08:23Z

My problem with this has always been that existing <script>s take place within the page's global scope. It's very strange to introduce something that looks so similar but behaves so drastically different. As such I've always preferred improving the story for creating workers from strings via new JS APIs, not new HTML.

fserb · 2019-07-18T18:08:27Z

Domenic, but that's the thing. People are already doing something that "looks so similar but behaves so drastically different". Except it's not explicit. Chrome has a bunch of code like this:

<!doctype html>
<html>
<body>
<canvas id='output' width='100' height='100'></canvas>
<script id='myWorker' type='text/worker'>
// wortker JS code
</script>
<script>
var blob = new Blob([document.getElementById('myWorker').textContent]);
var worker = new Worker(URL.createObjectURL(blob));
</script>
</body>
</html>

So we already have code that is on a <script> tag but that doesn't run on the page scope.

I don't think a better String to Worker API would solve this. People will keep doing things like the code above because you get the benefits of the <script> tag (syntax highlight, being on the same file, etc). Nobody wants to write code inside multi-line strings.

So my thinking is: we can make this less hacky, clearer and simpler for people to use.

domenic · 2019-07-18T18:29:34Z

I agree people can hack up something that is unintuitive and weird today. I don't think that's necessarily a great motivation for adding such semantics to the platform natively, especially if---as you explain---it's pretty easy to do without native support.

I think we could make it even easier, while maintaining the current invariant that in-page scripts run in the page's process, via a new string API. So that your example would become

<!doctype html>
<html>
<body>
<canvas id='output' width='100' height='100'></canvas>
<script id='myWorker' type='text/worker'>
// wortker JS code
</script>
<script>
var worker = Worker.fromString(document.getElementById('myWorker').textContent);
</script>
</body>
</html>

This seems to strike a better balance to me.

fserb · 2019-08-26T15:45:14Z

I'm not sold that your example is cleaner than what I suggested, but I agree that removing the Blob/createObjectURL would be a good thing, so I'm fine moving in this direction.

Do we know anyone on Firefox or Safari that deal with workers?

asutherland · 2019-08-26T16:20:19Z

Hi, I work on Firefox Workers. I would have the following concerns with the element based solution:

We're trending towards setting explicit headers for policy-related reasons on all Worker-variant globals. While Blob workers already have necessitated inheritance policies, creating an element-based affordance that might then give way to means of tunneling the headers or effects of those headers through would seem to complicate the spec a lot.
Lifecycle issues.
- We can currently GC workers if the Worker binding gets GC'ed and there are no "message" listeners on it and/or the Worker cannot possibly generate a message given its state, but this declarative mechanism would bias towards creating a static root for the worker unless the page goes out of its way to remove the element.
- When would the worker start? As soon as the </script> tag gets hit? Would we make the worker's creation obey "async" and "defer"?
- An auto-starting worker potentially is going to race the page-load itself for resources.

I am agreed that anything we can do to reduce calls to createObjectURL and the potential leakage of the underlying blob by a failure to revoke the URL would be an improvement. So I like the idea of Worker.fromString. But Spec-wise, it seems like that potentially just amounts to syntactic sugar for createObjectURL/new Worker/revokeObjectURL? Unless we wait for a means of creating a Worker directly from a Response?

domenic · 2019-08-26T16:26:12Z

Unless we wait for a means of creating a Worker directly from a Response?

Interesting, that'd be basically as convenient, and would help with some of the header-based issues:

var worker = new Worker(new Response(document.getElementById('myWorker').textContent, headers));

However I guess such responses would have no URL, so we'd have to do a bit of legwork to figure out what that means... and it might amount to reinventing similar semantics to blob: URLs, hmm. But at least it's work that would pay off in other forms (i.e. for creating other resources from Response instances).

asutherland · 2019-08-26T19:08:29Z

Yeah, to be clear, I meant assume we've solved whatwg/fetch#49 first. (And maybe assume that we provide some means of stuffing a URL into the response on the basis that ServiceWorkers allow origins to lie to themselves about such things, and that w3c/ServiceWorker#1026 and the proposal at w3c/ServiceWorker#1195 (comment) ties into our desire for the above fetch issue to be resolved, in which case we wouldn't have to roundtrip through a ServiceWorker.)

RReverser · 2020-04-30T12:07:13Z

I came across this issue while searching the tracker to see if someone proposed creating a Worker from Response before. @domenic's snippet looks pretty close to what I had in mind, but I was wondering if it would make more sense to add a Promise-based API similar to WebAssembly.instantiateStreaming:

Worker.instantiate('...').then(worker => ...);
Worker.instantiate(fetch('...')).then(worker => ...);
Worker.instantiate(new Response('...')).then(worker => ...);

With this, we could kill two birds with one stone and provide both a way to create workers from custom requests/responses, as well as a way to get load/error status in a unified way.

annevk added topic: workers addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest labels Jul 18, 2019

domenic mentioned this issue Oct 16, 2020

Declarative worklets proposal/tracking issue #6073

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Declarative WebWorker? #4786

Declarative WebWorker? #4786

fserb commented Jul 18, 2019

annevk commented Jul 18, 2019

fserb commented Jul 18, 2019

annevk commented Jul 18, 2019

domenic commented Jul 18, 2019

fserb commented Jul 18, 2019

domenic commented Jul 18, 2019 •

edited

Loading

fserb commented Aug 26, 2019

asutherland commented Aug 26, 2019

domenic commented Aug 26, 2019

asutherland commented Aug 26, 2019

RReverser commented Apr 30, 2020

Declarative WebWorker? #4786

Declarative WebWorker? #4786

Comments

fserb commented Jul 18, 2019

annevk commented Jul 18, 2019

fserb commented Jul 18, 2019

annevk commented Jul 18, 2019

domenic commented Jul 18, 2019

fserb commented Jul 18, 2019

domenic commented Jul 18, 2019 • edited Loading

fserb commented Aug 26, 2019

asutherland commented Aug 26, 2019

domenic commented Aug 26, 2019

asutherland commented Aug 26, 2019

RReverser commented Apr 30, 2020

domenic commented Jul 18, 2019 •

edited

Loading