Hacker News new | past | comments | ask | show | jobs | submit login

I love async but very rarely use await. It makes inversion of control patterns super easy and avoids deep logic and instead get something much more readable.

I treat await as a code smell and always triggers me to evaluate if we really need to be waiting for the result in this place. Most of the time they shoukd just return the promise or put something in a then.

People are going to misuse stuff but it doesn’t mean we shouldn’t use appropriate tools when appropriate.

EDIT: this is especially true for NodeJS where lots of frameworks are promise/async aware and support you returning a promise to them.




There is zero reason to use async without await, unless I’m missing something.

The number of await calls in your codebase should always be greater than the number of async modifiers.


Async implicitly wraps the return in a promise if it otherwise wouldn’t return one. Useful for wrapping logic that otherwise would be synchronous. So, syntactic sugar so you don’t have to have “new Promise” to wrap what would otherwise be synchronous logic.

Instead of using await you can instead just use “.then(() => part that needs to wait)”, or a chain of “.then” on the returned promise to sequence dependent logic. Or if needing to wait on a set of async actions you have “Promise.all”. It is much more explicit on what part actually needs to wait instead of “everything after this in the function block”.

I prefer to just compose promises which allows you to sequence actions that need it. It is a code style preference but I find I end up with clearer codebases doing it this way.


> Async implicitly wraps the return in a promise

Yes. Without using await, it's basically the same thing as just changing `return result` to `return Promise.resolve(result)`.

> Useful for wrapping logic that otherwise would be synchronous.

The logic is still synchronous, except now the return value is just wrapped in a promise.

> Instead of using await you can instead just use “.then(() => part that needs to wait)”

I don't understand why this would ever be desirable versus just calling the function synchronously. If for some reason you really need `.then` I would just wrap the call to the function, instead of making the fn async, `Promise.resolve(myFn()).then(() => part that needs to wait)`

> if needing to wait on a set of async actions you have “Promise.all”.

You can pass non-promise values to `Promise.all`, and it will work fine, although I don't see why you would do it intentionally. ie `await Promise.all([1, Promise.resolve(2)])// resolves to [1,2]`.

> It is much more explicit on what part actually needs to wait

If anything it's less explicit, you are disguising the true behavior. You making a synchronous function look like it's async when it isn't.

It's also going to suffer a small performance penalty, although it shouldn't really matter unless the function is used in some tight loop. When I tested calling a very simple `return 1` function, making it async resulted in the benchmark taking twice as long.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: