JSON parsing (also in the async function) is CPU-heavy, though. If you had a huge, huge amount of JSON it might be worth it. Maybe.

Not in this case, because copying data to and from a web-worker uses "Structured Copy" which is about as fast as JSON unmarshaling, but in this case it's actually doing significantly more work:

* read request

* parse from JSON to an object

* read the data from the object in the worker to the main thread

* create a new object in the main thread with the data from the worker

Those last 2 steps are about as slow as a JSON.stringify and JSON.parse, and are completely unnecessary. As others have said, adding some filtering to the example makes this example worlds better.

I'm not a browser expert, but my understanding is that JS is still single-threaded in the browser, despite allowing asynchronous functions.

Greenlet would execute the function in an entirely different thread, which isn't possible without the Web Worker API.

Someone please correct me if that's wrong!

It's single threaded, but with async I/O.

That means that any I/O doens't block the main thread, and other parts of JS can execute.

This example provides literally no benefits, and actually is a performance hit from converting the data from JSON, then sending it back to the main thread (which itself copies the data in a method similar to converting back to JSON then back to an object again in the main thread).

It's true, the example could be better. However - adding any form of data pruning to the example would immediately show the benefit. JSON parsing happens in the worker, and only a small subset of data is actually serialized and sent back to the main thread.

Yeah, that would be a great way of handling it. The other would be to parse out the data and insert it into the IndexedDB and then in the main thread only pull out what is needed

(I had to do exactly that for a B2B app that was receiving hundreds of MB of data a while back)