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 agree. I think the article takes a simplistic view of the use cases in an effort to make the post consumable but in doing so, misses some of the point behind the syntax.

One thing I really like async/await for is you can use them in for-loops. It makes it significantly easier to do async work in what was previously very synchronous.

I thought await in loops was a big no no, unless it has changed since I last checked?

Doesn’t it remove any opportunity for parallelism, making the loop take much longer than it would with a Promise.all?

Or am I missing something?

You're right(ish) - the async functions would not run in parallel. But sometimes that's either fine, or I don't want them to run in parallel.

It’s funny; I never thought of it as a desirable behaviour.

To each their own!

Sometimes you want to do things sequentially, so for..of x { await } is the way to go

If you want parallelism: await Promise.all(x.map(...))

> Being able to store tasks/promises and reuse/await them later is a clear advantage

This sounds like horrible spaghetti. I can understand you might need to do it in exceptional circumstances, but I wouldn’t make a habit of it.

99% of the time you'll be storing promises in order to await on them in the same async method.

Those other 1% of times make for quite intuitive solutions, I think. For example, a cache. Most caches are request => already finished response, but with a lookup of promises you can easily do request => in-progress responses, for de-deplication.

Graceful shutdown & startup are two use cases that I used this for, just today.

When my express server gets a SIGTERM I want it to stop accepting new requests but finish pending requests before exiting.

Likewise during startup, the HTTP server is currently up before all resources are available - DB backends and the like. So I await a .ready promise before all requests iff we are not inited.

It can be abused into spaghetti for sure, but actual use cases are not that exotic imho