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" <[email protected]>님이 작성: > 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 <[email protected]> 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 >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
