Hm, wasn't `return await promise` a tiny performance issue? So you returns a promise, but await it first, and then the return will be wrapped in a promise again as required by the async keyword. Maybe that's outdated dogma...? - ThreadSky

About ThreadSky

pvdz.ee • 15 days ago

Hm, wasn't `return await promise` a tiny performance issue?

So you returns a promise, but await it first, and then the return will be wrapped in a promise again as required by the async keyword.

Maybe that's outdated dogma...?

Comments

jfsiii.bsky.social•14 days ago

Paging @jasnell.me and @nodeland.dev

nodeland.dev•14 days ago

it’s 100% correct that return await uses a promise and it adds a spec of overhead. However, the tradeoff is that you get a slightly better stacktrace that include that codepoint in case an exception is thrown.

Some codebases cares more about perf. Other the better debuggability.

ashley-c.bsky.social•14 days ago

Also might be needed if using finally blocks either explicitly or implicitly via https://github.com/tc39/proposal-explicit-resource-management

pvdz.ee•14 days ago

Yeah i totally get the try case.
I was just a little surprised to learn that the eslint rule now defaults to all. Thought maybe something changed.

byk.im•14 days ago

It's probably the stacktrace aspect. We had these (without await) in yarn for performance but when something went wrong, good luck hunting down the actual call site.

pvdz.ee•14 days ago

Yeah the stacktrace reason makes sense. Thanks for the confirmation :)

Posting Rules

Be respectful to others
No spam or self-promotion
Stay on topic
Follow Bluesky's terms of service

Comments

Posting Rules

Reply