What Is Web Worker? Where Can It Be Used?

In the early days of frontend development, there wasn't much to process on the frontend side, mostly simple event handling and animation effects. However, as frontend development has matured, developers are handling more and more tasks on the frontend, and the original JavaScript design gradually became insufficient for new demands.

Various technologies have emerged in the frontend community to fill these gaps, allowing developers to perform more complex operations on the frontend. Web Worker and Service Worker, commonly heard in frontend development, fall into this category.

What Is Web Worker?

The core concept of Web Worker is to open another thread for background computation, so that complex calculations don't block JavaScript's main thread.

To understand this, we need to look at JavaScript's development from a historical perspective. When JavaScript was originally designed, computers and browsers of that era were far less powerful than modern ones, so JavaScript was designed as a single-threaded language where only one task could be executed at a time, which was fine back then.

However, modern browsers are capable of multitasking, allowing frontend developers to have the browser handle different things simultaneously. In this context, JavaScript's single-threaded design becomes a limitation, making it impossible to effectively utilize the computing power of modern multi-core CPUs in browsers.

Specifically, if a complex computation is running, other tasks cannot be processed at the same time. From the frontend perspective, this means the screen might freeze for users, resulting in a poor user experience. However, browsers are clearly capable of doing more, so if we could have a mechanism to distribute heavy, thread-blocking tasks, we could solve this suboptimal user experience.

Web Worker exists to solve this problem. Through the browser's Web Worker API, we can execute tasks in another thread (often called Worker Thread in the community). From JavaScript's main thread perspective, this is like having a helper in the background executing tasks, so it doesn't get blocked when processing computations and can continue doing other things.

As shown in the diagram, through Web Worker, if we have a computation that takes considerable time, we can first pass it to the Worker thread through postMessage for processing. Once the computation is complete and results are obtained, we pass them back to the main thread, handling them in parallel. This way, the main thread never gets blocked.

Specific Use Cases for Web Worker

When discussing specific use cases for Web Worker, it's recommended that readers not memorize these scenarios but instead think about them in context. Web Worker was created to solve the problem of complex computations on the frontend blocking the main thread, causing the screen to freeze and resulting in poor user experience.

To elaborate, when users perform an action, they expect immediate UI feedback. If something prevents this immediate feedback from happening, you should consider using Web Worker to move the blocking computation to another thread.

A common use case is in many image management websites (like Flickr or Google Photos). When loading images, they simultaneously parse the images to get their metadata. This process requires converting images to ArrayBuffer format, which takes computation time. This is a perfect scenario for Web Worker. Once the Worker thread completes the processing, it passes the obtained metadata back to the main thread, preventing main thread blocking.

It's important to note that while opening another thread for computation intuitively seems to improve performance, this isn't always the case. Before reading further, readers are encouraged to pause and think about the tradeoffs of opening another thread.

When using Web Worker, an obvious cost is the message passing cost. As shown in the diagram above, passing data from the main thread to the Worker thread, processing it, and then passing results back to the main thread all involve steps that, while not time-consuming individually, still add overhead. So if a computation can be completed quickly, especially one that doesn't significantly impact user experience, it might be better to handle it on the main thread without the extra overhead of sending it to a Worker thread.

Furthermore, accelerating main thread processing has other approaches beyond Web Worker. For example, a popular approach in the community is to use WebAssembly to have other languages (like Rust) handle time-consuming computations, which in some scenarios can be faster than using Web Worker.