mohsen1 / async-json Goto Github PK

I feel that polyfills are dangerous: you are wrapping a sync method as async method. With the callback / promise you are simulating a async method, but the implementation is synchronously and will block the main thread.

Two solutions: implement a native JSON.parse async or move the sync JSON.parse work at the end of the event loop. I was working in the last option in this repository: https://github.com/Kikobeats/json-parse-async

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.

This idea is mostly coming from this thread in Twitter. Because Promises are not cancelable and there could be cases that user wants to cancel the parse or stringify method for other reasons while it's being processes maybe we should not use promises and use streams or observables instead.

Let's say some day it will be possible to parse JSON in a background thread. That's what this whole thing is about. There still would be a problem with reviver and replacer functions. There are two options:

• they run on the main thread. In case of parsing we either produce intermediate structure in a background thread and then build actual object in the main thread or we can parse in a background thread without taking reviver in account and do some post-processing in the main thread after. Either way this damages performance (except in the latter case we can skip post-process if no reviver is passed). Things are reversed with stringify: pre-processing instead of post-processing.
• they run on a background thread. This means two things: we need to spawn full VM for each thread dedicated to JSON tasks and we need to serialize functions via toString to pass them to a different VM which breaks closure semantics.

Both options seems pretty bad, so it's probably easier to leave out reviver and replacer arguments altogether.

Mostly from nodejs/node#2031 (comment)

Consider following code:

let obj = {foo: 1};
JSON.stringifyAsync(obj, result => console.log(result));
delete obj.foo

There could be a thread collision issue here. What can be done?

Hey @domenic could you review this before I publish it? I sent you an email earlier...

For reference (might be useful for polyfill also) there is this library http://oboejs.com/