const id = reader.u32() ?? await A
The A function resolves to a singleton instance of Promise, which is updated by the class QuickReader. It means multiple instances of QuickReader will overwrite each other. In other words, A only works with the last instance of QuickReader created. I'm not sure if that's the intended behavior, but I would have designed it differently.
This fact not only limits the performance as described in the article, it can also lead to subtle bugs due to reordering of callbacks.
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?