Multi-threading in JS, and what you can do with it!
Multi-threading in JS?
What about async?
Still, the individual lines of code - broken down into their instructions for the CPU - will still run through it sequentially. None of it is actually happening side-by-side. In other words: async allows us as developers to program in a way that provides an abstraction to parallel programming, but really, it isn’t.
Anyway, Web Workers are cool. Because the browsers have their foot down on OS-level and can allocate memory and threads as much as they like, they can provide a workspace for code to run on a separate thread also! This is essentially what the Worker API does for you. You may create a worker and give it some code to execute on a separate thread, allow it to talk back to the main application thread, and have a party!
We’ve visualised how this works and looks like in the browser in the following demonstration.
In a nutshell: You can schedule some work in the demo. Work in the form of prime number discovery. It will count up to a limit defined by the primes slider. It will list all the primes it finds on the way. This is the work that needs to be performed by the machine. You can schedule the work on the main thread or on the separate thread.
On the other hand, the green button allocates a new worker (and thus thread) to work on its own, separate from the thread handling the critical rendering path of the browser. You might notice you’re free to do in the UI whatever you want to do! Also, it’s important to note that the tasks will finish in parallel now because that’s what’s really going on! It’s actually multi-threading all of that number-crunching for you.
Also, the same work performed on the main thread finishes slower than that same work on a separate thread. I speculate that this is because there is other work to be done on the main thread away from the UI or even the app in question.
The toughest bit in this, is knowing how you can use this. Essentially there shouldn’t be a use-case for it in the first place. That’s the thing I hear most of the time. Since you don’t usually want to do heavy number-crunching in your front-end. That is usually something your back-end should handle before sending the data ready for consumption to the front-end.
But we don’t live in an ideal world, and I used to work for a company where the API was something that grew very organically as time progressed. A very familiar story. I remember we had to populate a table with huge amounts of data. Data that - at that point - was already loaded in store, but required mapping and some computational aspect to it before it could be displayed. The UI locked up. We could have created a separate endpoint in the back-end to give us the data we required and just display that, but that team would defend themselves and say that the cost of transporting the same data twice was ridiculous. Eventually, we had to come up with a way to deal with that, but thinking back about it right now, we could have used Web Workers to at least prevent the UI from locking up.
Web Workers are cool! Definitely! The thing is that you won’t see them in production that much. Which is OK, but we shouldn’t forget that it works, and does so quite well! If your UI locks up, and it’s not due to recursion or an infinite loop, you should be thinking of loading that work off to separate threads. Have a blast!
We’ll probably go into more detail on Audio Worklets and Web Assembly to reveal that applications in the browser can be truly powerful and seamless. More on that in a future blog... 🎉