You gotta appreciate the tenacity of Surma. He’s been advocating for Web Workers as a path forward to better-feeling websites for a lot of years now. He’s at it again making sure we all understand the landscape:
[…] regardless of where you look, multithreading is used everywhere. iOS empowers developers to easily parallelize code using Grand Central Dispatch, Android does this via their new, unified task scheduler WorkManager and game engines like Unity have job systems. The reason for any of these platforms to not only support multithreading, but making it as easy as possible is always the same: Ensure your app feels great.
Surma, “The State Of Web Workers In 2021”
So pretty much every platform has its own version of multi-threading, including the web. It’s just that on the web we have to sort of “fight” against the single-threaded nature of JavaScript by using Web Workers (which are “universally supported” if you’re wondering about that). The question is: use them how and for what? For the latter, Surma shows off an example of a game where “the entire app state and game logic is running in a worker.” For the former, the helper library comlink looks like a big reduction in toil.
Personally, I wish popular tooling would just kinda… do it. I don’t know what that really looks like, but it kinda feels like developer outreach isn’t really moving the needle on this. What if popular tooling like Apollo — which is in charge of a lot of “app state” — were to magically handle all of that off the main thread. Does that make sense? Is it possible?
To answer your last question, “Is it possible?”, I’d say yes, absolutely. Ultimately using a worker is like any other async process, you start it off and wait for a response. Assuming you have a way to handle the async state of, for example,
fetchorlocalStorageyou should have minimal problems integrating workers into that too.I’ve been using them to process large-ish datasets to great success and will probably lean in even harder when I do similar projects in the future. The improvement over my old “break up the data array and process it in small batches, yielding to the browser with
setTimeoutinbetween” approach is hard to understate!Whoever wants to try multithreading in web frontends, there is a Framework already Out there doing it. The Performance is absolute insane.
Please give it a try and Check it Out.
https://github.com/neomjs/neo
Thanks Sebastian!
Regarding the neo.mjs project:
The key concept is “an application worker being the main actor” which fits well into Surmas idea of an actor model.
In short: your apps (including components) live within an app worker which leaves main threads as idle as possible. They create the workers setup, forward UI related dom events to the app worker and apply delta updates from the virtual dom worker.
You can either use dedicated workers for SPAs or shared workers for multi window apps.
The latest addition is an offscreen canvas worker:
https://tobiasuhlig.medium.com/rendering-3d-offscreen-getting-max-performance-using-canvas-workers-88c207cbcdc2?source=friends_link&sk=7ee0851ff6043c4a79248ff5a20a23fc
Best regards,
Tobias