Hacker News Reader

Comment by hayksaakian | Hacker News Reader

Hopefully with async/await we can all put this behind us.

In my own projects, async/await has made improved readbility and reduced errors.

async/await helps a lot, but there are still a few common errors with them...

1) Not calling promises in parallel. Easy to do because it's impossible to run them in parallel with just "await", need to use Promise.all() or something.

2) Forgetting to write "await". If you try to use the return value then now you have a Promise object instead of the actual value. But the worst is when the code doesn't use the return value. Then it has a really subtle race condition that's hard to find. Or if the promise has any errors, then you might get the dreaded "Unhandled promise rejection" with a useless stack trace, and you might need to search the entire codebase to find where it happened.

I've seen a lot of developers at the place I work make the mistake you outline in #1. Always something I'm watching out for in code reviews...

For the first I wonder if we could solve this with array syntax:

   const [foo, bar] = await [async1(), async2()]

You can use await on the promise returned by Promise.all()

Yes, the correct syntax is:

    const [foo, bar] = await Promise.all([async1(), async2()])

TypeScript helps immensely in this case.

It's easy to run tasks in parallel with just "await". Just start your tasks without await, store the promise in a variable, and then use await later when you actually need the value.

That's fine, but you'll still only be able to block on one promise at a time. If you want to wait until all promises have resolved you still have to use Promise. all.

Promises are started eagerly, so

    const xP = getX();
    const yP = getY();
    const x = await xP;
    const y = await yP;

is just as parallel as

    const [x, y] = Promise.all([getX(), getY()]);

Whoops, you're right! I hadn't thought it through.

Also sometime I don’t want promise.all but I do want them in parallel somewhat but with a max concurrency setting. Still have to pull out the old async.js package for that one and use it’s maxLimit.

I have found cases in which async/await won’t cut it quite as cleanly as “return new Promise”. AWS Cognito’s API has functions that take an object parameter with properties onSuccess and onFailure. If these functions are being called with programmatically created values within promises you can use “await new Promise” but that means declaring an additional async/await function (and therefore a promise) that resolves with the resolution of another promise. When you are explicitly defining all of your operations in TypeScript you notice these anti-patterns. Of course you could also declare these functions elsewhere and use function parameters instead of scoped variables. In my opinion the best solution is the one that is most justifiable when described to an outsider while walking through the code so I sometimes feel grateful for the freedom to choose my promise implementations on a case-by-case basis. When the relevant code is entirely my own, however, async/await is the most elegant.

Async/await is pure syntactic sugar and should not reduce errors unless the Promise syntax was implemented incorrectly.

I'm not sure I fully understand. Interoperability is as simple as wrapping the non-standard API, no? This way you have a standard calling style in your code. It's not a weakness of async/await that some libraries don't have promise friendly APIs.

The API in this example is promise-friendly, it is just intended for callback syntax; providing two situational callback options.

This an implementation issue. Of course you can wrap the non-conformant external code but in this case that means accepting anti-patterns in order to gain the benefit of syntactic sugar. Writing API wrappers that do nothing more than wrap traditional Promise callback code as a rule is a poor substitute for allowing developers to choose the most appropriate implementation. Instead that would favor meaningless promise chaining and unless you ignore a library’s type definitions that is pretty hard to miss. Using async/await isn’t doing anything different in the same sense that using a class is no different than using a function that returns an object. The question is one of readability and flexibility, no one syntax is inherently better that the other because the interpreter does not know the difference.

Async/await is inherently better than other syntax though, for a number of reasons, and the interpreter does indeed know the difference. If anything the interpreter knows much more about your intent, rather than “oh this function takes a `callback` parameter that’s a function” and can optimize based on that info.

It is not better, the two have different use cases. If you are using setTimeout to delay then you need a callback. Being so obsessed with the syntax that you right your code twice is the only wrong solution. While the AsyncFunction is used only by async statements and expression it uses Promise under the hood. In terms of performance it is not a good idea to make assumptions like that, performance can only be determined by testing.

I think it could be a linter rule to force async functions await any calls to async/promise functions. Or an explicit way to ignore it.

Reply on news.ycombinator.com