I'll often use both, but not in the same places... async functions when called return a promise... you can await anything that returns a promise.
I'll often refactor some pieces that make sense as functions that return a straight promise (especially if using callback code.
const foo = () => new Promise((res,rej) => {
someCbFunction((err, result) => err ? rej(err) : res(result);
});
There are times it's just easier to think imperatively... A great example is a promise that will retry N times on rejection before raising the rejection... try this with promises alone and you'll drive yourself bonkers.
As a matter of fact, retry it's not very hard to write in pure promises:
const retry = (fn, times) =>
times >= 0
? fn().catch(() => retry(fn, times-1))
: fn();
I don't understand the point of article at all. The only point I see is "Code *looks* like an old code from 80s". So this is bad only because it's not new and shiny? Okay.
I'll often use both, but not in the same places... async functions when called return a promise... you can await anything that returns a promise. I'll often refactor some pieces that make sense as functions that return a straight promise (especially if using callback code. const foo = () => new Promise((res,rej) => { someCbFunction((err, result) => err ? rej(err) : res(result); }); There are times it's just easier to think imperatively... A great example is a promise that will retry N times on rejection before raising the rejection... try this with promises alone and you'll drive yourself bonkers.As a matter of fact, retry it's not very hard to write in pure promises: const retry = (fn, times) => times >= 0 ? fn().catch(() => retry(fn, times-1)) : fn();