Use selective-await to reduce 99% of JavaScript async call overhead

Re:Use selective-await to reduce 99% of JavaScript async cal... by arneg on Friday June 24, 2022 @06:23AM (#31859795)

Not easily possible. The issue is that the specification mandates that the resolve callbacks must be queued as Jobs and cannot be called immediately.

This fact not only limits the performance as described in the article, it can also lead to subtle bugs due to reordering of callbacks.

[ Parent | on HN ]

Re:Use selective-await to reduce 99% of JavaScript async cal... by eurasiantiger on Friday June 24, 2022 @07:06AM (#31860066)

Is there some other way to do that except process.nextTick() and queueMicroTask()?

https://nodejs.org/api/process.html#processnexttickcallback-...

> It is very important for APIs to be either 100% synchronous or 100% asynchronous.

As I understand, this implementation sidesteps this hazard by providing separate internally coupled sync/async APIs kept in sync by convention around the critical internal and external conditionals. Is this correct? Is it just this sync/async code path convention that makes the implementation safe as opposed to a function directly returning a value or a Promise?

The convention does make it kludgy to use, but native alternatives would defeat the purpose or become the hazard mentioned in the documentation.

Have you considered creating a Babel macro for this?

[ Parent | on HN ]