This means it has one call stack and one memory heap.
There has been an interesting point/counter-point combo recently along these lines.
You should always use Web Workers.
The worst time of day to travel. For many it’s not possible to travel at any other time of day because they need to get to work by 9am.
This is exactly what a lot of web code looks like today: everything runs on a single thread, the main thread, and the traffic is bad. In fact, it’s even more extreme than that: there’s one lane from the city center to the outskirts, and quite literally everyone is on the road, even if they don’t need to be at the office by 9am.
An example of getting something off the UI thread: State management.
David Gilbertson must have read that and wrote:
I saw an article recently making the case that updating a Redux store was a good candidate for Web Workers because it’s not UI work (and non-UI work doesn’t belong on the main thread). Chucking the data processing over to a worker thread sounds sensible, but the idea struck me as a little, umm, academic.
(Looking at that 100ms thing, it’s worth noting that a major point Surma is making is that the world is full of low-end phones — and who knows what 100ms on a high-end phone is when translated to on a low-end phone.)
var myWorker = new Worker(worker.js);
But they don’t have to be – you can inline them or use a lib. The API isn’t awful, but it’s not amazing either. Surma has a library for that: Comlink.
Surma’s crusade on this is quite the long term effort. It was a feature at 2018’s Chrome Summit with A Quest to Guarantee Responsiveness: Scheduling On and Off the Main Thread and again in 2019 with The main thread is overworked & underpaid, but this time with nearly six times the views at the time of this update:
And he’s not alone. Here’s Alex MacArthur on adjusting his thinking about event handlers to accommodate doing things off thread.