Standardize ES Worker

Park Hyeonu nemo1275 at
Wed Oct 26 04:43:14 UTC 2016

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list