Proposal of Multithread JavaScript

Leo Dutra at
Wed Nov 2 13:56:42 UTC 2016


(function foo() { ... })()   // sync and single threaded
(*async *function() { ... })() // async and parallel


*Leo Dutra, **on **Facebook <>
**and LinkedIn

2016-11-02 11:38 GMT-02:00 Leo Dutra < at>:

> ECMA introduced Promises and async-await in JS. This improves coding in an
> amazing way, reducing the control developers need to wrap an AJAX call or
> async I/O.
> JavaScript used to be script and not a language. Classes, workers, sound
> control, GL rendering, Node.js modules (with OS conversation), incredible
> GC strategies and compilation on V8 and Mozilla "monkeys"... the list goes
> on and on.
> Almost all the features provided by old mature platforms, like Java, .NET
> and etc. For browsers, the newest JS features provide consistent tools for
> productivity and quality code.
> But there's a huge step to accomplish.
> ECMA introduced workers. Node.js came up with streams, native process
> spawn and libuv thread pool. This is a lot, but not enough.
> All I hear about Node.js is how it is great for quick message I/O and bad
> for aggregations and impossible for parallel tasking. Again, we have
> workers and processes, but not green threads.
> I invite you to take a quick look at Akka and OTP (Erlang). More than it,
> I will argument: workers and process spawn are the latent desire for
> parallel and starting one of these are not "cheap" or waiting in a pool.
> We use streams extensively in Node.js and most frameworks hides it from
> us. Call it magic, I call it pragmatism.
> Now, async, await, Promises ("Futures")... we can make it all work in
> parallel.
> This would explore more libuv in Node.js and browsers could handle it too,
> seamlessly.
> Each function could be run in a green thread, pulled from a browser/libuv
> pool, allowing Node.js and browsers to process aggregations and heavy
> rendering without heavy start costs and complicated message control through
> events.
> More, I ask why not, and "single thread nature of JS" looks more like a
> bad legacy from old browsers. We can do it in pieces, like the proposed
> async-await and, on better days, provide a Parallel API (something like *parallelize(()
> -> { // parallel stuff here })*).
> I wanna leave you with the possibilities in mind and bully this single
> thread dogma.
> You have been told.
> *Leo Dutra, **on **Facebook <> **and LinkedIn
> <>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list