> Songbird mixes promise into Function.prototype

> Songbird adds promise to Object.prototype

Eek

Meh. Non-enumerable. You can opt instead for bluebird's promisifyAll when you require.

>async/await

in my experience, async/await is a great way to layer indirection and obfuscation over what is still callback hell. it may look better in the editor, but it's hell to debug.

When I initially encountered event -based processing (libevent in C), those callbacks were indeed difficult to wrap my mind around. But I learned to structure the code in the editor, keeping everything together which made it manageable. I 've worked with node for a couple of months now, and I find promises to be more confusing, because it obfuscates the callback in my mind, and makes it look like ordinary function calls.

The advantage of promises is that you can return them as a type, you can't do that with a callback. If you fetch something from a database , your data access object can return a promise and let the client code deal with the result. Promises are composable by nature, callbacks are not.

I can see how it can be hard to follow returns sometimes but if the promises are used well, it reads and flows really nicely.

Here's a good article on promises that helped me, especially since I had seen a lot of misuse in JS land before I started using them:

https://pouchdb.com/2015/05/18/we-have-a-problem-with-promis...

async/await is tiny amount of sugar over generators and promises (virtually the only thing that changes is `yield` -> `await` and `function*` -> `async function`), not callbacks.

<removed>

EDIT: Oops, I misread the parent. You're right, async/await isn't easy to debug, but it's getting better, and it's a tradeoff. For now, I recommend debugging the compiled code (using generators) without source maps to avoid some of the quirks of source maps. In my experience, the tradeoff is worth it for new node.js developers because it offloads the asynchrony contract (e.g., calling a callback OAOO) to the language.