Creator here. Yes it's a wrapper around the Web Worker and Node Worker Threads API. In order to create an inline worker, the user provided function is serialized using .toString() and any provided yield statements (which specify outside variables, functions & imports) are extracted. Because JavaScript objects are passed by reference, we can get the references by running the user function on the main thread first (iterating over each yield statement), and stop on the last yield so the main thread doesn't execute the rest of the function. Then, whenever a thread mutates a shared variable, the new value is send or transfered to the main thread, which then updates the variable using the object's reference.
everyone will update their unnecessary react framework that is used 90pct of the time for something that should have been a static page, to use multithread. then bloggers will write about how you need to enable it to get smooth 120fps on your button animations. then events will not be handled right and you will scratch your head why clicking the smooth 120fps button fails to update your profile or whatever. because it was enabled on a non multithread aware code and tests were never updated or existed in the first place, and bugs will only be fixed after hundreds of users bother to contact support. as usual
I do have a function that needs to run in a webworker, as it would block the UI for somewhere between 1s and 30s, but I can't see myself adopting this. It looks readable like normal JS. And so it hides its nature from the casual reader. The package does have the usual deadlock problems, so I totally expect this to cause problems.
