Comment by gatherhunterer | Hacker News Reader

Comment by gatherhunterer | Hacker News Reader

Parent Full thread

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