*TL;DR:*

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

Additional:
parallel.run()
parallel.stream()
parallel.sleep()
parallel.waterfall()
...



*Leo Dutra, **on **Facebook <http://www.facebook.com/leodutra.br>
**and LinkedIn
<https://www.linkedin.com/in/leobr>*

2016-11-02 11:38 GMT-02:00 Leo Dutra <leodutra.br at gmail.com>:

> 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 <http://www.facebook.com/leodutra.br> **and LinkedIn
> <https://www.linkedin.com/in/leobr>*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20161102/86a0cd0c/attachment.html>

*TL;DR:*

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

Additional:  
parallel.run()  
parallel.stream()  
parallel.sleep()  
parallel.waterfall()  
...

*TL;DR:*

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

Additional:  
parallel.run()  
parallel.stream()  
parallel.sleep()  
parallel.waterfall()  
...

*TL;DR:*

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

Additional:
parallel.run()
parallel.stream()
parallel.sleep()
parallel.waterfall()
...