JavaScript Multithreading (2023)(github.com)
github.com
JavaScript Multithreading (2023)
https://github.com/W4G1/multithreading
8 comments
Readme does not explain how it works... I guess it's some wrapper around web workers?
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.
absolutely zero js code needs this but it will be the must-have feature for FE frameworks.
and the world will suffer a multitude of common-for-users-but-edge-cases-for-the-devs triggering all sort of bugs for all of 2024.
and the world will suffer a multitude of common-for-users-but-edge-cases-for-the-devs triggering all sort of bugs for all of 2024.
It seems the library has a pretty clear way for error handling. What kind of edge cases are you referring to?
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
why?
So that heavy operation doesn't block the main UI thread?
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.