Proposal of Multithread JavaScript

Michael J. Ryan tracker1 at
Thu Nov 3 22:41:08 UTC 2016

Workers define a clear boundary...  In Windows, only the main thread can
touch the ui..  and in Linux, threads are almost as expensive as

Just the same, I'm okay with threads, but feel that not having shared state
I'd better as you will avoid a large amount of potential bugs.  Having
clear separation still allows you to solve many problems where threading
would help in a clean and clear way.

There's been other discussions of a load a threaded module, which could
have a clear line in the sand.  I wouldn't even mind coroutines or a good,
safe csp implementation...  However, those lines would take longer to
develop safely and take longer still to lock down appropriately.

Having worked as threads and allowing a lighter weight message would negate
a lot of the negatives you mention... It doesn't have to be a serialized
message.  Adding an immutable object probative would do the trick (given
fewer hurdles).

All ui/Dom access needs to be serialized anyway, I don't think that's a
good example of why we absolutely need shared state threads.

On Nov 3, 2016 12:19 PM, "Leo Dutra" < at> wrote:

> I have defined many times, but you guys are in love with workers.
> A little look in Java's Runnables would demonstrate de nature and
> difference I'm bringing to this thread.
> Workers can't even modify DOM directly...
> Very different of go routines, Java/Scala threads etc.
> Workers require way more control and coding by the nature of their
> declaration and messaging. A worker lives and awaits... A thread is run
> against a living spawned process and is garbaged after the usage.
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list