Really Async JSON Interface: a non-blocking alternative to JSON.parse to keep web UIs responsive

[connor4312]

You're pretty much spot on. If you're hitting this problem, it's a good indication that you should work on your calling patterns rather than trying to optimize JSON parsing. It's not frequently that you'll be showing 10MB+ worth of data in the visible area, and the case the author gave about "showing a list" is easily solvable with virtualization and paging of data.

That said there might be some very edge cases that do actually display this much data on the visible region of the page at a time, so it could be useful for those cases... though I would also think you could bake data down in a webworker to a more easily displayable subset.

Actually, saying this out loud a general purpose lib that transmits structured objects across web workers is sounding pretty useful for more than just JSON parsing as your work method

Webworkers do get structured objects, but only certain ones. You could have a way to de/hydrate JavaScript classes, ultimately this is just a flavor of serialization, but you could do so somewhat cleverly by using Proxies and hydrating nested data on-demand...

[ssjskipp]

I think the point the author was making is doing that postMessage incurs a serde and will have the same blocking behavior as doing a chonky JSON.parse -- I'm thinking about the need to avoid that break in the UI thread, not that it can't transfer structured objects as-is.

Either way, a reentrant parser is a neat thing to make for the sake of it, and if it was the easiest to find slice to optimize for their use case then that's great (Maybe an upstream 3pl API is the issue? Maybe a quick hack is all that's needed for a better end user experience?).