Scenario where to async/await over Promise?

Question

I know that async/await are essentially the same under the hood (at least in V8). I've used both extensively and I noticed that I avoid async/await more and more. I also noted a significant decrease in momentum whenever I was forced to write code based on async/await.

• Are there scenarios in which async/await is objectively better than Promises?

• ...If not, why do some stick to async/await?

• What option should be used for flow control? Does this depend on the length of the flow?

• Is there a clear choice if the goal is to produce code that's easy to read and understand?

You always use promises, regardless of what syntax you use for them. Make sure you have understood promises, and that `await` is a replacement for `then` calls only. There hardly is any scenario where not using `await` is simpler. You might want to show us some code where you found `then` easier to use, explain your reasoning, and show us how you struggled with getting an equivalent `async`/`await` version of the code. — Bergi, Feb 01 '19 at 18:30
@plalx No, it's syntactic sugar for promise `then` calls specifically. And it doesn't allow to deal with synchronous processes either - it allows making asynchronous processes *sequential* easily, though. — Bergi, Feb 01 '19 at 18:36
Try using `await` in a for loop and then try to change that to strictly use Promises. It's hard! — Evert, Feb 01 '19 at 18:48

Max · Accepted Answer · 2019-02-01T18:55:55.293

There is an awesome article about that by Gokul N K which I agree with pretty much:

https://hackernoon.com/should-i-use-promises-or-async-await-126ab5c98789

From my point of you, I'd say async/await is just better in terms of waiting for promise resolves (async function returns promises, btw).

For example, I use async/await more frequent in node environment when I call async function that manipulate data (DB or 3rd party API). Like:

// server

async function removeComment(commentId) {
  const comment = await getComment(commentId);

  if (comment) {
    const commentAuthorUserId = await getUser(comment.userId);
    notifyUser(commentAuthorUserId);

    await removedCommentFromDB(comment);
    res.json({ status: 'ok' });
  }
}

The code above is not real, but shows how cool the code looks without multiple then nesting. Btw, use try ... catch for error handling when you use await many times (more than twice) in one async function. Otherwise, you can use .catch() for await promise as @Bergi mentioned.

In other hand, I use Promises in browser to control flow, but not manipulating data.

For example:

// client

function onRemoveClick(commentId) {
  service.removeComment(commentId).then(() => {
    DOM.removeCommentElement(commentId);
  });
}

because If I'd use await it turns into:

async function onRemoveClick(commentId) {
  const response = await service.removeComment(commentId);

  if (response.status === 'ok') {
    DOM.removeCommentElement(commentId);
  }
}

which is a quite longer and also it always resolves a HTTP Response which is not obvious for the first glance.

"*always use `try ... catch` for error handling when you use `async/await`.*" - [I can not quite agree on the "always"](https://stackoverflow.com/a/44664037/1048572). — Bergi, Feb 01 '19 at 18:47
@Bergi you are right, for a single `async` call or scoped error handling you'd want to user `catch` for await promise, but it ruins the whole beauty of `async/await` flatness. Edited. — Max, Feb 01 '19 at 18:54
Yeah, just saying that in some cases you want a non-flat control flow, and then `try` gets in the way. — Bergi, Feb 01 '19 at 18:56
Sometimes (especially DB manipulation in node), I just don't use either. I jsut set error handling hooks and write much cleaner code and in case error happen server just returns 500 Error and I then I can see the actual error in logs — Max, Feb 01 '19 at 18:59

Scenario where to async/await over Promise?

1 Answers1