How workers work

A worker is another place to run code

A worker is JavaScript that runs apart from the page. The page has its own event loop: the queue of jobs it works through one at a time, such as clicks and drawing. A worker has a separate one.

So a worker can do big jobs, like working out numbers or reading a large file. Meanwhile the page still answers clicks and keeps drawing. But a worker is not free:

• Starting a worker takes work.
• Sending data to it and back takes work too.

A worker is worth it only when the job is bigger than those costs.

The earlier Web Workers lesson showed how to use a worker. This lesson looks inside. It answers two questions:

• What must the browser do before the worker reads its first message?
• What must the browser do to carry a value from one side to the other?

The last lesson was about agents and realms. A worker is one real browser tool built on those ideas. The next lesson, SharedArrayBuffer & Atomics, shows memory that both sides really can share.

One tiny worker round trip

Start with one message and one reply. Here is the plan:

• The page starts a worker from a file named worker.js.
• The page sends an order for two teas.
• The worker reads the order and turns the item and the amount into text.
• The worker sends that short text back.

1const worker = new Worker("worker.js");2worker.onmessage = (event) => {3  console.log(event.data);4};5worker.postMessage({ item: "tea", qty: 2 });

1self.onmessage = (event) => {2  const { item, qty } = event.data;3  self.postMessage(item + ": " + qty);4};

In main.js:

• Line 1 starts the worker from worker.js.
• Line 2 sets onmessage: the function that runs later, when the reply arrives.
• Line 5 sends the order with postMessage.

In worker.js, self is the worker's own global object. It plays the part that window plays on a page. The worker joins the two values into the text tea: 2 and sends it back. The page logs tea: 2.

1const message = { item: "tea", qty: 2 };Run2function handleMessage(order) {3  return order.item + ": " + order.qty;4}5const delivered = structuredClone(message);6const reply = handleMessage(delivered);7console.log(reply);

Notice what the worker does not do. It does not reach into the page and change a button or a heading. It only sends data back. The page then decides what to show.

Each worker has its own engine and event loop

An isolate is the engine's name for one separate JavaScript world. It has its own values, its own global names, and its own clean-up of unused memory. Browsers build this in different ways. The simple rule still holds:

• A worker has its own global names.
• A worker has its own queue of jobs.
• A long job in the worker does not block the page's queue.

1const pageName = "Asha";2const workerName = "Mina";3console.log(pageName);4console.log(workerName);

Line 1 stores a name for the page. Line 2 stores a second name. Lines 3 and 4 print Asha and Mina. No worker starts here; the names only stand for the two sides. A real worker would not see either page variable. It starts with its own self. It has no page document, so it cannot reach the DOM, the page's tree of elements. It cannot read the page's global names either.

Separate event loops explain a common surprise. postMessage does not run the other side's handler right away. It only puts a job in the other side's queue. The reply is queued in the same way. So treat both as results that arrive later.

This keeps the page quick to respond. But it also means there are no shared variables. So:

• Put every value the worker needs into the message.
• Put the result the worker makes into the reply.

The tea example above does exactly that. The worker never reads a page variable.

Why starting a worker costs work

new Worker("worker.js") looks like one short line. But the browser has a lot to do before the worker is ready:

• Make a new global object for the worker.
• Set up the worker's own event loop.
• Fetch the script file, read it, and run its top lines.

How long this takes is not a fixed number. It depends on the device, the script size, whether the file is already saved in the browser, and how busy the browser is.

1const startupSteps = ["global", "event loop", "script"];2 3console.log(startupSteps.join(", "));4// A new worker needs all three before it can read its first message.

Line 1 lists the three setup steps. This is only a teaching model: the browser does not keep a real array like this. Line 3 prints global, event loop, script. All three happen before the worker can read the tea order.

So a worker can be a poor choice for a tiny sum. The page pays three times:

1. The setup.
2. Sending the message.
3. Sending the reply back.

Some jobs repeat many times, such as making small preview pictures or building a search index. For those, keep a few workers alive and reuse them. Then you pay the setup once, not once per job.

A pool does not make things faster by itself. It needs a few rules of its own:

• A queue of jobs that are waiting.
• A way to cancel jobs nobody needs any more.
• A plan for when a job fails.
• A limit on the number of workers, so they do not slow down the rest of the browser.

A later lesson, Parallel patterns with workers, covers these rules.

1const jobs = ["filter tea", "filter coffee"];2const workers = ["worker-1", "worker-2"];3 4const assignments = jobs.map((job, index) => ({5  job,6  worker: workers[index % workers.length],7}));8 9console.log(assignments.map(({ worker }) => worker).join(","));

Line by line:

• Line 1 lists two jobs.
• Line 2 lists two workers that are already running.
• Lines 4 to 7 give each job to a worker. % gives the remainder of a division, so the job numbers 0, 1, 2, 3 go to workers 0, 1, 0, 1. The workers take turns.
• Line 9 prints worker-1,worker-2.

This model only shows who gets which job. A real pool must also wait for a worker's reply before it gives that worker the next job.

Structured clone copies data

Structured clone is the browser's built-in way to copy a value for a message. It visits every part of the value and builds a brand-new copy for the other side. You can call it yourself with structuredClone(value).

A small order is quick to copy. A big array full of nested objects has many more parts to visit, so it takes more work.

1const order = { item: "tea", qty: 2 };2const copy = structuredClone(order);3order.qty = 3;4console.log(copy.qty);

• Line 1 makes an order with qty 2.
• Line 2 makes a separate copy called copy.
• Line 3 changes the original's qty to 3.
• Line 4 prints 2, because the copy was made before the change and does not follow the original.

1try {2  structuredClone(() => "tea");3} catch (error) {4  console.log(error.name);5}

Some values cannot be copied, and trying throws an error named DataCloneError. Inside try, line 2 tries to copy a function. The copy fails, so the catch part runs and line 4 prints the error's name, DataCloneError. Two common cases that fail:

• A function. It is code tied to the place where it was made, and the message format has no way to copy that.
• A DOM element, such as a button. It belongs to the page, and the worker has no page.

Model copy work before you optimize

The size of a message does not tell you the whole cost of copying it. But it is a good first question: how much data goes across, and how often?

• A message with many nested objects has many parts to visit.
• A large message sent on every screen redraw can cost more than the work you moved into the worker.

The playground below has two modes. Copy is the structured clone you just saw. Transfer hands the data over instead of copying it; the next section explains how.

1const messageSize = 12;2const mode = "copy"; // change to "transfer"3const report = modelMessageCost(messageSize, mode);4 5console.log(report.copyWork);6console.log(report.senderHasData);

Change the message size, then switch between Copy and Transfer.

• In Copy mode, the sender keeps its data. The copy work grows with the message size.
• In Transfer mode, there is no copy work. The receiver gets the data, and the sender no longer has it.

This is a teaching model. It does not measure real time.

In a real app, first make the message smaller when you can. Send an ID, a short result, or only the part that changed, not the whole app's data. Then measure the real app. The shape of your objects and the browser matter more than any guess.

Transfer hands data over instead of copying

An ArrayBuffer is a block of raw bytes, such as the data of a picture or a sound. A transferable is a value like this that can be handed over instead of copied.

To hand it over, you pass a transfer list: an array of the things to move. The bytes then move to the other side. Nothing is copied. The sender's buffer is left empty. We say it is detached.

1const buffer = new ArrayBuffer(8);2const received = structuredClone(buffer, { transfer: [buffer] });3console.log(buffer.byteLength);4console.log(received.byteLength);

• Line 1 makes a buffer of eight bytes.
• Line 2 hands the buffer over. { transfer: [buffer] } is the transfer list.
• Line 3 prints 0. The old buffer is empty now. byteLength is the number of bytes in a buffer.
• Line 4 prints 8. The new buffer, received, has all the bytes.

postMessage(buffer, [buffer]) follows the same rule. The second argument is the transfer list.

1const buffer = new ArrayBuffer(8);Run2const received = structuredClone(buffer, { transfer: [buffer] });3console.log(buffer.byteLength);4console.log(received.byteLength);

A transfer is not shared memory. It is a handover to one new owner. Use it for a large block of bytes that only the other side needs next. Sometimes both sides must see the same bytes at the same time. That needs SharedArrayBuffer and careful rules about who writes when. The next lesson covers it.

Shared workers and worklets

The worker you have seen so far is a dedicated worker: one page owns it. Browsers have other kinds too.

A SharedWorker can serve several pages or tabs from the same site (the same origin). Each tab talks to it through its own port, a MessagePort. A port is like a private phone line between one tab and the worker.

This helps when related tabs should share one connection or one small helper service. It still talks only by messages. It stays alive only while some tab uses it, so do not expect it to keep running after all the tabs close.

1const worker = new SharedWorker("shared-worker.js");2const port = worker.port;3 4port.start();5port.postMessage({ type: "open-cart" });

• Line 1 connects to the shared worker by its script name.
• Line 2 takes this page's port.
• Line 4 starts the port, so messages can flow.
• Line 5 sends a small request.

This code has no Run button. The lesson cannot open a second tab or keep a shared worker alive for you.

A worklet is different again. It is a small script that the browser calls during one special job:

• An audio worklet helps process sound.
• A paint worklet helps draw part of the page.

Worklets only do that one job and follow its rules. They do not replace a dedicated worker.

Two more facts about worker kinds:

• A dedicated worker runs a plain script by default. If the script uses import, start it with new Worker("catalog-worker.js", { type: "module" }).
• A service worker is another kind. The browser starts it when an event comes in and stops it when it is idle. So it is not a place for long background work.

The table below compares the kinds. Each row is one kind: who uses it, and what it is good for.

Pick the simplest kind that fits the job:

• One page's background job: a dedicated worker.
• Several tabs from the same site working together: a shared worker.
• Sound or drawing work that the browser calls: a worklet.

None of them can touch a page's DOM.

Choose a worker shape for a real app

Picture a shop's search page. It gets a large list of products once. Then it filters the list after every key the user types. Here are three ways to use a worker:

• Start a new worker on every key press. This pays the setup cost again and again.
• Send the whole product list back and forth each time. This pays the copy cost again and again.
• Keep one worker that already has the list, and send it only the short search text. This is usually the best choice.

Next, decide on a message plan (sometimes called a protocol). Write down:

• What each request looks like.
• What reply you expect.
• What happens if the user changes their mind halfway.
• Which side owns any block of bytes.

Give every job an ID number, so an old reply cannot replace a newer search result. Stop or reuse workers when the work is really done.

1let latestJobId = 2;2 3function requestSearch(query) {4  latestJobId += 1;5  worker.postMessage({ id: latestJobId, query });6}7 8worker.onmessage = ({ data }) => {9  if (data.id !== latestJobId) return;10  console.log(data.results.join(", "));11};

• Line 1 remembers the ID of the newest job.
• Lines 3 to 6 give each new search a bigger ID and send it with the search text.
• Line 8 handles each reply that comes back.
• Line 9 stops early if the reply's ID is not the newest one, so an old reply is ignored.

This matters when someone types fast. An older search may finish after a newer one. Its result must not replace the newest result on the page.

The same idea works outside the browser. Node.js has workers too, in a module named worker_threads. The code below starts a Node worker, sends it the tea order, and prints the reply reply tea: 2. The lesson's tests run it in Node to check that.

const { Worker } = require("node:worker_threads");

const worker = new Worker(
  `const { parentPort } = require("node:worker_threads");
  parentPort.on("message", ({ item, qty }) => parentPort.postMessage(item + ": " + qty));`,
  { eval: true },
);

worker.once("message", (reply) => {
  console.log("reply", reply);
  worker.terminate();
});
worker.postMessage({ item: "tea", qty: 2 });

• Lines 3 to 7 start a worker. Its code is written right in the text, and { eval: true } tells Node to run that text as the worker's script.
• Inside the worker, parentPort plays the part of self: it gets the order and posts tea: 2 back.
• Lines 9 to 12 wait for one reply, print it, and stop the worker.
• Line 13 sends the order.

Common worker misconceptions

• “A worker can touch the page DOM.” It cannot. The worker sends a result, and the page changes its own elements.
• “Messages share my object.” A normal message carries a copy. If you change the original later, the copy does not change.
• “A transfer is just a faster copy.” A transfer hands the bytes over. The sender's buffer is left empty.
• “More workers always means faster.” Each worker costs setup, messages, and memory. Too many workers also fight over the same computer, and the gain can disappear.
• “A worker pool is only about speed.” Its queue and its rules for cancelling jobs decide which results the user sees. Get them wrong, and the page shows the wrong answer.

The table below puts similar-sounding ideas side by side. Read each row as: the term, what it really means, and what it is easy to mix it up with.

Three questions clear up most mix-ups. For any value, ask:

• Where does this value live right now?
• Was it copied, or handed over?
• Which event loop will handle the next message?

Practice exercises

const cart = { item: "tea" };
const copy = structuredClone(cart);
cart.item = "coffee";
console.log(copy.item);

const buffer = new ArrayBuffer(4);
structuredClone(buffer, { transfer: [buffer] });
console.log(buffer.byteLength);

Check your understanding

For each question, first ask which idea it tests:

• separate event loops,
• copied values,
• handed-over bytes,
• or a kind of worker.

Key takeaways

• A dedicated worker has its own global names and its own event loop. It cannot use the page's DOM.
• Starting a worker takes setup work. Reuse workers when the same big job repeats.
• Structured clone makes a separate copy of a message. Bigger, more nested data takes more work to copy.
• A transfer hands an ArrayBuffer over. The sender's buffer is left empty, with a byteLength of 0.
• A shared worker serves several tabs from the same site through ports. A worklet runs inside one special browser job, such as sound or drawing.

Coming next: SharedArrayBuffer & Atomics. There, two sides really share the same memory, so they must take care not to write at the same time.