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/c6d18017/attachment.html>

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.