I Avoid Async/Await

This, very much this.

    async function() {}

is much nicer than

    function() {
      return new Promise(
        (resolve) => resolve()
      )
    }

Try ou kotlin coroutines. The suspend keyword really helps out reasoning.

> Give better cues that we are in an asynchronous mental model

The `async` keyword(!) is objectively a clearer signal that the code in question is asynchronous. That's why type-checkers use it to prevent you from doing dumb stuff like awaiting in a synchronous function.

> In simple cases express the code at least as cleanly as async/await

It's pretty hard to see much of an argument here. How can the promise version ever be seen as "at least as clean"?

    await someTask()
    // vs
    someTask().then(() => ...);

Even beyond the syntax here, the promise forces you into at least one level deep of nesting, which instantly makes it much trickier to manage intermediate variables, which either need to be passed along as part of the result (usually resulting in an unwieldy blob of data) or the promises need to be nested (pyramid of doom) so that inner callbacks can access the results from outer promises.

> Provides a much cleaner option for more complex workflows that include error handling and parallelisation.

If you've somehow come to the conclusion that `Promise.all` doesn't work with `async/await` then you have probably misunderstood the relationship between `async` functions and promises. They're the same thing. Want to parallelise a bunch of `await` statements? You can still use `Promise.all`!

I do occasionally find try-catch to be awkward, but that's because it creates a new lexical scope (just like promise callbacks do). I also think the consistency from having one unified way to handle errors in sync/async contexts justifies it.

All async/await is built on promises/futures/tasks, which themselves are built on yield/generators. Most modern languages have converged on this and they are not different paradigms but rather just newer syntax.

Async/await is better for expressing concurrent logic more tersely and in the common "sync" format, and failure to understand what it means is just that, a failure in understanding.

There's no convincing argument here to use "promises instead async" because it's the same thing.

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.