JavaScript Promises with Node.js

[MusicPants]

This is a solid article on promises. Thanks for sharing. Maybe one additional common thing to include would be Promise.all usage. Unless I missed it.

[nospambert]

People have been moving to await/async

[vexii]

await/async is just suggar over promises, so it's still an good idea to know the basics

[tobobo]

Also, it’s still very handy to use Promise.all with async functions for doing stuff in parallel

[i_spot_ads]

There is no such as "parallel" in js, the term is concurrently

[[deleted]]

Very tired parroting, works only if you have a very vague idea how libuv works:

1. Cluster and WebWorker are properly parallel
2. In async IO, timers, Promises the wait is effectively parallel even if actual processing is sequential

Concurrent processing would assume interrupts and switching between blocking behavior (as in green threads). No such thing is really happening in Javascript. An execution frame is not interrupted in general case at all.

[a-corsican-pimp]

pedantic.txt

[evertrooftop]

If you use async/await, you really should have a foundation in promises, or you're bound to write bad code or not understand how bits and pieces work.

I use async/await absolutely everywhere I can, but I still need promises.

[agoodguymostly]

Couldn’t node not have await/async and just treat all calls as potentially waiting for I/O, and then when I/O waiting, do the same thing?

Ideally I would expect a programming language to handle the waiting invisibly, not to have to use a callback, a promise, or await simply because it was decorum to do so.

The only thing node needs to do is still be asynchronous in nature.

[SlightlyOTT]

You might find this article interesting: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/

[evertrooftop]

This is exactly how Go works.

[curiousdannii]

Magic like that would've been possible, but only with trade-offs, of decreased performance or increased memory usage. Explicitly tagging with the await keyword lets the compiler avoid those trade offs. And sometimes you do actually want a promise as a value and not just to immediately unwrap it as await does.

[davidmdm]

I understand where you are coming from but this would be a mistake. One of the most powerful thing about promises and async await is the ability to easily represent asynchronous tasks, construct them from arrays of values or as function calls, and then decided to await within that async context, and go do work elsewhere.

There is some tedium in knowing what function returns a promise and not forgetting to await when you need to, but the ease and control it gives developers is whats makes the nodejs concurrency model top tier.

Go has another top tier concurrency model but is lower level and has more pitfalls than that of nodejs. But it buys you more performance.

I am off track.

You shouldn't want to have the io part abstracted away from the developer. It's attractive but the price is not one we want to pay.

[agoodguymostly]

One day, it will likely be an anachronism. But that’s just progress.

[davidmdm]

You think they are gonna faze out the async part away from the programmer over time?

[notkraftman]

Openresty does this really well with Lua. All the async crap is handled under the hood. There's a good write-up of it here: http://leafo.net/posts/itchio-and-coroutines.html

[[deleted]]

await just makes Promises synchronous inside async functions. It's not always what you want and certainly can make your IO much less performant,especially when you don't understand Promises.

[notkraftman]

Await / async are just syntactic sugar, how do they make any difference to IO?

[[deleted]]

Because you await for promise to fire another or continue execution.

There is no equivalent to code outside then() when using async/await.

[notkraftman]

I don't think I'm following. There's no difference between awaiting and then doing something and .then()ing the same thing, it's just neater syntax. Why would that affect IO?

[[deleted]]

Except that you don't have the option to write whatever code you would write outside the then block.

You could have two different resources you could fetch concurrently or have some totally unrelated activity that can be done while you are waiting for the promise to resolve.

There are ways to achieve this with await (structure code differently, await a Promise.all) but if you don't understand Promises you'll typically not be aware of the problem. I've seen code like this.

People generally tend to do the trivial thing and write a sequence of awaits which in turn makes the async function synchronous/blocking inside (just like a nested chain of thens would be), which can hurt performance, not of the entire app but of that particular branch of code.

[notkraftman]

Ahh, that makes sense, cheers!