Standardize ES Worker

Michał Wadas michalwadas at
Thu Oct 27 13:48:40 UTC 2016

Resending, because I forgotten to include es-discuss mail.

Anyway, can you explain it more about mismatch between WebWorker and modern
> js idioms

Currently we put emphasis on request-response model - we request something
from function (returning Promise/taking callback) and we wait for single
return value. Workers are different beasts - they can emit messages on
their own and don't have to emit ANY messages on completion.

I think API adressing this issue would look like:

// main.js
const worker = new Worker('worker.js');
worker.request('ajaxCall', {url: ''}); // return Promise
resolving to Response object
worker.request('undefinedMethod'); // return rejected Promise

// worker.js

self.on('ajaxCall', (data)=>{ return Promise.resolve(new Response); });

On Wed, Oct 26, 2016 at 6:43 AM, Park Hyeonu <nemo1275 at> wrote:

> I agree that we need additional modification from WebWorker spec. What I
> mean on the first post is that we (likely) can make standard Worker spec as
> a (mostly) subset of WebWorker spec so current codes using WebWorker need
> not to be changed.
> Anyway, can you explain it more about mismatch between WebWorker and
> modern js idioms?
> 2016. 10. 26. 오전 6:05에 "Isiah Meadows" <isiahmeadows at>님이 작성:
> Maybe with modification. I currently feel workers are a bit heavy (with
>> their event driven nature), and they most definitely don't follow the
>> idioms of the modern JavaScript language (very promise heavy).
>> On Sun, Oct 23, 2016, 02:11 Park Hyeonu <nemo1275 at> wrote:
>>> Now we're about to standardize thread-shared memory for EcmaScript(
>>> But how about the thread
>>> itself?
>>> For this topic, I don't think we should develop another thread spec for
>>> ES as we already have a nice one - WebWorker. This spec allows
>>> multithreading in web client and it's well-adopted on most modern browsers.
>>> So all we need to do is just care some web-specific points of the api.
>>> Fortunately it's already `new Worker()` not `new WebWorker()` and not so
>>> many points should be fixed for it.
>>> For the case to import web spec to ES spec, there's already a case like
>>> this - Typed Array. It's originally standardized in Chronos group as a part
>>> of WebGL spec, and adopted to ES later.
>>> The spec I'm mentioning here is html5 apis including WebWorker,
>>> MessageChannel, Structured Clone Algorithm, Transferable Object.
>>> Sounds nice, isn't it?
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list