Completely my feelings too. He doesn't actually address this, and it is actually the really painful part about promises which async/await makes infinitely better.
I have had cases where converting .then(...) code to async/await made the code infinitely easier to understand/reason about and made it trivial remove bugs which were present due to the complexities of dealing with control flow logic.
It strikes me that the author is just already "used to" promises and as such is trying to justify their preference for them with examples which they believe "prove" that promises are "better", but actually fail to do so. For every single one of their examples, async/await is no worse, if not better.
For example, their argument about inadvertently serialized work with the the two save calls. They are claiming that ".then()" is more obviously serializing than the "await" keyword, which is a highly subjective claim. If there is a problem here, it's that some developers don't understand/know about all the asynchronous tools which are available and so are unaware of the option of using Promises.all(...).
Another argument for async/await compared to promises is the following:
try
{
await doSomething();
}
catch()
{
// Do a particular error handling for doSomething() failing
}
try
{
await doSomethingElse();
}
catch()
{
// Do a different particular error handling for doSomethingElse() failing
}
What's the best way to reproduce this in promises only land, for example, does the following work?
doSomething()
.catch(() => {
// Do a particular error handling for doSomething() failing
})
.then(() => doSomethingElse())
.catch(() => {
// Do a different particular error handling for doSomethingElse() failing
});
I think it works, but I honestly don't know for sure offhand and to be sure I would need to check the documentation for promises, whereas for the async/await approach, there is no question. And if the above doesn't work, then I would have to call the .then() from inside the first .catch() block, which is awful code to read and interpret.
It's the same code. Async/await is just syntactic sugar over the promise syntax.
To me depends on what you are doing, there are cases where using .then()/.catch() and .finnally() makes the code more concise and simpler than using async/await.
.catch() returns a promise so you can call the then method on it again, yes. If you throw from either catch or then it will trigger the next catch method.
I have had cases where converting .then(...) code to async/await made the code infinitely easier to understand/reason about and made it trivial remove bugs which were present due to the complexities of dealing with control flow logic.
It strikes me that the author is just already "used to" promises and as such is trying to justify their preference for them with examples which they believe "prove" that promises are "better", but actually fail to do so. For every single one of their examples, async/await is no worse, if not better.
For example, their argument about inadvertently serialized work with the the two save calls. They are claiming that ".then()" is more obviously serializing than the "await" keyword, which is a highly subjective claim. If there is a problem here, it's that some developers don't understand/know about all the asynchronous tools which are available and so are unaware of the option of using Promises.all(...).
Another argument for async/await compared to promises is the following:
What's the best way to reproduce this in promises only land, for example, does the following work? I think it works, but I honestly don't know for sure offhand and to be sure I would need to check the documentation for promises, whereas for the async/await approach, there is no question. And if the above doesn't work, then I would have to call the .then() from inside the first .catch() block, which is awful code to read and interpret.