'Off The Main Thread'

JavaScript is single-threaded, which means it has only one call stack and one memory heap. This often results in performance stuttering and unresponsiveness of page elements or the entire website. If JavaScript is assigned a large number of tasks, it will be busy with these tasks and cannot quickly handle other things, such as event handlers.

Some interesting opinions and rebuttals have emerged around this issue recently.

Das Surma has always advocated transferring as many JavaScript tasks as possible from the main thread. In fact, when using Web Workers, he advises: Always use Web Workers. Web Workers are the main method to separate JavaScript from the main thread. Paul Lewis likens this issue to the morning rush hour: the worst time of travel of the day. Many people cannot travel at other times because they have to arrive at their workplace before 9 o'clock. This is exactly what a lot of web code looks like today: everything runs on a single thread (main thread) with a lot of traffic. In fact, it's even worse than that: there's only one driveway from downtown to suburbs, and almost everyone is on the road, even if they don't need to arrive at the office by 9 o'clock.

Surma compares the practice of often referring to "main thread" as "UI thread" in other languages. If your task is UI-related, execute on the main thread; if not, execute on other threads. He explored this issue in depth in this episode of Web Platform Podcast – 194: Off the Main Thread. I think this may change the attitude and mindset of JavaScript developers.

An example of decoupling tasks from UI threads is state management.

David Gilbertson probably read this and wrote: I recently saw an article that updating Redux storage is ideal for Web Workers because it is not a UI worker (non-UI worker does not belong to the main thread). It sounds reasonable to transfer data processing to worker threads, but the idea makes me feel a little academic.

David's main point seems to be that some of the heavy JavaScript tasks we need to deal with are responses to user-initiated operations, and the user needs to wait for the task to complete anyway, so it is acceptable for the UI to be unresponsive during this period. But for any non-user-initiated task—and taking more than 100 milliseconds—he agreed that using Web Worker would be helpful.

(About these 100ms, it is worth noting that one of Surma's main points is that there are many low-end phones in the world - who knows what the 100ms on high-end phones would look like on low-end phones.)

The main trick to separate tasks from the main thread in JavaScript is to use Web Workers. It's not a hack, Web Workers is indeed a native API that brings multiple background threads to JavaScript. Similar to Service Workers, they are usually located in another file:

 var myWorker = new Worker('worker.js');

But they don't have to be like this - you can inline them or use libraries. The API is not bad, but it is not great either. Surma created a library for this: Comlink.

Surma's efforts in this area are long-term. This is a feature at the 2018 Chrome Summit, with the theme of "A Quest to Guarantee Responsiveness: Scheduling On and Off the Main Thread" and reappeared in 2019 with the theme of "The main thread is overworked & underpaid", but this time it was viewed almost six times the time:

And he was not fighting alone. Alex MacArthur also talked about tweaking his view on event handlers to accommodate performing tasks on non-main threads.

The above is the detailed content of 'Off The Main Thread'. For more information, please follow other related articles on the PHP Chinese website!