Recently I have been tinkering with web workers and this is a comprehensive guide on everything you need to know to get started with using web workers.

If you want to skip reading the blog and checkout the code instead, here is the github repository which contains all the snippets.

Github Web Worker Repository

?

Table of Contents

• Common Misconceptions
• Web Workers Basic Setup
  • Web Worker Setup with Native JavaScript
  • Web Workers Setup with Comlink
• How to check if my worker was registered properly?
• Further Reading

?
?

Common misconceptions

So, what got me exploring web workers was that in a platform I was building a computationally heavy task was blocking the UI.
So I thought, 'Huh, okay, how do I make this not block the UI'? Shall I use setTimeout to make sure all the code in the main thread has finished execution, after which the computationally heavy task can run?

So here is the misconception — using setTimeout does not mean that the UI will not be blocked. Yes everything on the main thread will be executed before the setTimeout callback runs however, this callback runs in the main thread itself when it is popped out of the Macro Task Queue thus making the UI unresponsive.

To know more about how setTimeout’s work here are some references —

• Asynchronous JavaScript & Event Loop from scratch - Akshay Saini
• Event Loop, Web APIs, Task Queue - Lydia Hallie

?
?

Web Workers Basic Setup

JavaScript is inherently a “single-threaded language” but, web workers enable us to run computationally heavy code in a separate thread.

Before we get started here are few things to note -

• Web workers cannot interact with the DOM
• The web worker scope is?self, rather than?window.
• Workers are relatively heavy-weight, and are not intended to be used in large numbers. For example, it would be inappropriate to launch one worker for each pixel of a four megapixel image. [Ref - HTML Specification]
• Also, a web worker isn’t about making something take 2 seconds instead of 4 seconds, it’s about doing that thing with the DOM freezing for 0 seconds. [Ref - Web Workers are slow & that's okay - Calvin Metcalf]
• Workers may in turn spawn new workers, as long as those workers are hosted within the same?origin?as the parent page. [Ref - MDN]

?

Web Worker using native JavaScript

1. Create a new JavaScript file that contains the code you want to run in the worker thread. (say worker.js)
2. In the main script instantiate the worker -

const worker = new Worker("./worker.js")

Note: worker.js is not a module and cannot use import statements. yet. :')

To use worker.js as a module, specify type: module in the option of the constructor.

const worker = new Worker("./worker.js")

1. Data is sent to and fro the workers via a system of messages — both sides send their messages using the?postMessage()?method, and respond to messages via the?onmessage?event handler
2. To pass complex objects with cyclical references in postMessage() use the structuredClone method.
3. To terminate a web worker, use the terminate method of the Worker API. This does not offer the worker an opportunity to finish its ongoing operations; it is stopped at once.

const worker = new Worker('./worker.js', { type: 'module' })

?
Putting It All Together

Now, let's see how our code looks after integrating web workers.

Main Thread Code:

worker.terminate() 

Worker Thread Code:

// ...
function workerFunction() {
  // Don't spin up a new worker instance if the process has already been started.
  if (statusElement.textContent !== PROCESS_STATUS.PROCESSING && window.Worker) {
    const worker = new Worker('./worker.js', {
      type: 'module'
    })

    // Sending 10000000000000 to the web worker
    worker.postMessage(10000000000000)

    statusElement.textContent = PROCESS_STATUS.PROCESSING

    // This piece of code is executed after worker finishes its task and returns data. 
    worker.onmessage = function (event) {
      statusElement.textContent = event.data
    }
  }
}
// ...

And the result:

When we run the application, you'll notice that the computationally heavy task is executed without blocking the UI.

?

Web Worker Setup with Comlink

Comlink is a?tiny library (1.1kB), it removes the mental barrier of thinking about postMessage logic.

At a more abstract level it is an RPC implementation for?postMessage?and?ES6 Proxies.

A specific reason why I used Comlink was that I was unable to pass functions from the main thread to the worker using plain JavaScript. Using Comlink’s proxy I was able to easily pass a callback function from main thread to the worker. [Refer to this section]

To get started with using comlink in your project, install the library

const worker = new Worker("./worker.js")

To get started with this library we need to know about these following methods -

Comlink.wrap(endpoint)

• It wraps the worker's exposed object, returning a proxy that you can interact with as if it were a local object.
• The proxy will have all properties and functions of the exposed value, but access and invocations are inherently asynchronous. i.e. if a function returns a number, it’ll now return a promise for the number.

const worker = new Worker('./worker.js', { type: 'module' })

Comlink.expose(value, endpoint?, allowedOrigins?)

• The expose function exposes value from one thread to the other (i.e exposing an object from worker to the main thread)

worker.terminate() 

?

How to check if my worker was registered properly?

• To check if the worker file was registered in the web browser (I am using Chrome)
• Right click → Inspect, and go to the Sources Panel where you’ll find the worker file.
• When terminated, the worker file should not be visible in the Sources panel
• In case, you can still see the worker file after terminating the worker, chances are you’ve registered multiple workers and not all of them have been terminated.

?

The above is the detailed content of All you need to know about web workers to get started.. For more information, please follow other related articles on the PHP Chinese website!