async-json

async-json copied to clipboard

What strikes me about this feature is that we're asking developers to have some intuition about when something is too big to happen "fast enough" that they need to push it off to async.

In my experience, developers are notoriously bad about reasoning about JS performance, and this seems like a huge welcome mat with a neon sign on the door that says, "please, come abuse the heck out of me with bad jsperf tests backing you up."

I would strongly suggest that the specification be reworded so as to not require that an implementation actually do the processing on some background thread, but merely that they make the results available via a promise that will have (at least) an event-loop deferral to make the operation "async" (and yet not necessarily parallel, background'ish).

Then an implementation can make some guess based on input size if they should go to the trouble to do it on another background thread (a la Web Workers) or if they should just do a sync JSON.xxxx(..) call and resolve the promise with it right away.

From the calling code's perspective, the behavior will be predictably async, but from the implementation's perspective, the engine has a chance to do different things when it feels it's better to do so.

Thanks @getify. This makes a lot of sense. Myself personally would use async APIs all over the place without thinking about input size. I think it's implementor's job to determine is it worth spinning up a thread or not.

Also in case user is asking for a lot of async operation in a tick, implementation should decide what to do with it. Consider following example:

for (let i = 0; i < 1000; i++) {
  JSON.parseAsync(someString)
}

What should happen there? 1000 threads? a queue? I don't know. I don't want to know actually. It depends on the system program is running on. These are all on implementor side.

Certainly the spec should not require any given implementation. However, it definitely must, imo, have the semantics of a Promise, such that it resolves on the next tick (and not the current one). It's clearly the sole domain of the implementor how to optimize that.