Standardize ES Worker

Park Hyeonu nemo1275 at
Thu Oct 27 13:28:31 UTC 2016

I originally thought such functionality can be implemented on top of
current event based model, but request-response pattern is such commonly
used for workers so it's worth to consider including this to spec.

But the current event namespace already has it's own usage so how about
something like this?

// main.js
const worker = new Worker('worker.js')

const io = worker.stdio

io.send('someEvent', someData)
await io.once('ready') // yes, promise

const res1 = await io.request('someMethod', arg1, arg2) // resolved with
returned data

const res2 = await io.request('nonExistingMethod', weirdData) // rejected
promise, throw

// worker.js
const io = self.stdio

io.on('someEvent', data => { ... })

io.method('someMethod', (arg1, arg2) => { ... })


`Worker#stdio` will be an instance of `IOChannel` interface. It may also be
used like below.

// event handling within for-await
for await (let ev of io.listen('someEvent')) {

// more than stdio
const [chan, remoteChan] = Worker.createChannel(optionalName)
worker.stdio.send('newChannel', remoteChan)
await chan.once('ready')

P.S. please CC es-discuss at to let track this
thread properly

2016-10-27 4:20 GMT+09:00 Michael J. Ryan <tracker1 at>:

> My guess is that there is a desire to make an rpc-like request to a worker
> that returns a promise.
>     const result = await worker.handle(action);
> Where action is a single object... Returning a promise.
> On Oct 25, 2016 9:43 PM, "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