Standardize ES Worker

Michał Wadas michalwadas at gmail.com
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: 'example.com'}); // 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 gmail.com> 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 gmail.com>님이 작성:
>
> 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 gmail.com> wrote:
>>
>>> Now we're about to standardize thread-shared memory for EcmaScript(
>>> https://github.com/tc39/ecmascript_sharedmem). 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 mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20161027/cc924ad9/attachment-0001.html>


More information about the es-discuss mailing list