How workers work

A worker is another place to run code

A worker is JavaScript running away from the page's main event loop. It can calculate, parse, or prepare data while the page keeps responding to input and drawing frames. A worker is useful when the work is large enough to repay the cost of starting it and passing data across its boundary.

This lesson goes beneath the everyday Web Workers API lesson. The earlier lesson teaches how to use a worker. Here, the question is what work the browser must do before your first message is handled, and what it must do to carry a value across the boundary.

The previous lesson described agents and realms. A worker is one practical browser API built on that broad idea. The next lesson, SharedArrayBuffer & Atomics, changes the story by discussing memory that really can be shared.

One tiny worker round trip

Start with one message and one reply. The page makes a worker from a file named worker.js. It sends an order for two teas. The worker receives the object, calculates a total, and posts a small reply 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};

Line 1 of main.js starts the worker script. Line 2 gives the page a handler for the later reply. Line 5 sends plain data. In worker.js, self is the worker's own global object, similar in role to a global object for that worker. The reply logs tea: 2 because the worker combines the two values from this tiny order.

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 is not happening: the worker does not reach into the page and change a DOM element. It sends data back. The page decides what to render when its own event loop handles that reply.

An isolate and event loop per worker

An isolate is an engine's separate JavaScript world for values, globals, and garbage collection. Browser terminology and implementation details vary, but the useful model is firm: a worker has its own globals and its own queue of tasks. A long worker calculation does not run on the page's event loop.

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

Line 1 stores a page-side name and line 2 stores another ordinary value. Lines 3 and 4 print Asha and Mina. The names are small on purpose: a worker does not inherit either page variable. It starts with its own self, not the page's document or ordinary global object.

Separate event loops explain a common surprise: posting a message does not call the other side's handler immediately. It queues work for the receiver. Replies are queued too, so code should treat them as asynchronous results.

That separation protects page responsiveness, but it also removes convenient shared state. Put the values a worker needs into the message. Put the result it produces into the reply. The small round trip above does exactly that, so there is no hidden access to page variables.

Why starting a worker costs work

Starting a worker is not just calling a constructor. The browser must create the worker's JavaScript environment, arrange an event loop, fetch or load its script, parse it, and run its top-level setup. There is no useful fixed number of milliseconds: devices, cache state, script size, and browser work all change it.

1const startupSteps = ["global", "event loop", "script"];2 3console.log(startupSteps.join(", "));4// A worker must prepare these before handling its first message.

Line 1 names three pieces of preparation in a teaching model. Line 3 prints global, event loop, script. A browser does not literally use this array, but the output reminds us why worker startup is real work before the first order message can run.

This is why a worker can be a poor choice for a tiny calculation. The page pays setup, then message delivery, then reply delivery. For repeated jobs such as image thumbnails or search indexing, keeping a small group of workers alive can amortize that setup cost.

A pool is a design choice, not an automatic win. It needs a job queue, cancellation policy, error handling, and a limit so it does not compete with the rest of the browser. The next practical lesson is Parallel patterns with workers.

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 1 names two jobs and line 2 keeps two workers available. Lines 4 through 7 assign each job to one existing worker. Line 9 prints worker-1,worker-2. This is only a deterministic queue model; a real pool must still wait for each worker's reply before assigning its next job.

Structured clone copies data

Structured clone is the platform algorithm that copies many JavaScript and web values for messages. It walks supported data and creates a separate value on the receiving side. A small order is cheap to reason about. A large nested array means more values for the algorithm to visit and reproduce.

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

Line 1 creates an object with an array. Line 2 makes a separate copy. Line 3 changes the original array after the copy exists. Line 4 prints hot, not hot,large, because the copied array did not change with the original.

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

Functions cannot be cloned because a function carries executable code and surrounding details that a generic message format does not reproduce. DOM nodes cannot be cloned into a worker either: they belong to a document the worker does not have. This snippet prints DataCloneError.

Model copy work before you optimize

A byte count is not the whole cost of structured cloning, but it gives a useful first question: how much data crosses this boundary, and how often? A message with a nested object graph also needs traversal. A large message every animation frame can defeat the reason you moved work away from the page.

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. Copy mode says the sender keeps its data and the model performs work proportional to the message size. Transfer mode says the receiver gets the data but the sender no longer owns it. This is a teaching model, not a timing benchmark.

First make the message smaller when you can. Send an ID, a small result, or a changed slice rather than a full application state. Then measure the actual application, because object shape and browser support matter more than a guessed timing.

Transferables move ownership

A transferable is a value whose backing resource can move to another context. For an ArrayBuffer, passing a transfer list tells the platform to move the bytes instead of copying them. The sender's buffer is detached after the move.

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

Line 1 allocates eight bytes. Line 2 moves the buffer. Line 3 prints 0 because the sender no longer owns usable bytes. Line 4 prints 8 because the received buffer owns them. The same ownership rule applies with postMessage(buffer, [buffer]).

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

Transfer is not shared memory. It is a handoff. Use it for a large binary payload that has one next owner. If both sides need to observe the same storage, that is a different design with SharedArrayBuffer, synchronization, and the memory model.

Shared workers and worklets

A SharedWorker can serve several same-origin pages or tabs. Each client talks through a MessagePort. This is useful when related tabs should coordinate one connection or one small background service, but it still has a message boundary and lifecycle details to design.

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

Line 1 gets the shared worker by script name. Line 2 takes this page's port. Line 4 starts that port, and line 5 sends a small request. The code is marked as a browser API fragment because a lesson sandbox cannot promise another tab or the browser's shared-worker lifecycle.

A worklet is different. It is a lightweight module that the browser runs inside a specific pipeline. Audio worklets participate in audio processing; paint worklets participate in painting. They are narrow tools with pipeline rules, not general replacements for dedicated workers.

Pick the smallest API that matches the job. A dedicated worker fits one page's background task. A shared worker fits coordination between same-origin clients. A worklet fits browser pipeline work. None grants access to another page's DOM.

Choose a worker shape for a real app

Imagine a product search page that receives a large catalog once, then filters it after each keystroke. Starting a new worker on every keypress wastes startup work. Sending the full catalog back and forth repeats cloning work. Keeping one worker and sending a small query can be a better boundary.

Write a small message protocol: what request is sent, what reply is expected, what happens if the page changes its mind, and who owns any binary data. Give jobs an ID so an old reply cannot overwrite a newer search result. Terminate or recycle workers when the work is really finished.

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 newest job ID. Lines 3 through 6 give every outgoing search a newer ID. Line 9 rejects a reply that belongs to an older request. This small rule matters when a user types quickly: an older, slower result must not replace the newest result on the page.

The Node-only probe below is real runtime evidence that a Node worker_threads worker receives a message and replies. The browser API has a different module name, but the independent message-and-reply shape is the same idea.

import { Worker } from "node:worker_threads";

const worker = new Worker(
  `import { parentPort } from "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 });

Common worker misconceptions

• “A worker can touch the page DOM.” It cannot. Send a result and let the page update its own document.
• “Messages share my object.” Ordinary message values are copied, so later mutations do not cross over.
• “Transfer is just a faster clone.” Transfer changes ownership and detaches the sender's buffer.
• “More workers always means faster.” Startup, messages, memory, and CPU contention can erase the gain.
• “A worker pool is only an optimization detail.” Its queue and cancellation rules are part of application correctness.

The simple check is ownership. Ask where a value lives now, whether it was copied or moved, and which event loop will handle the next message. That question prevents most worker-boundary confusion.

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, name the boundary first: separate event loops, copied values, moved ownership, or a browser-specific worker shape.

Key takeaways

• A dedicated worker has separate globals and an event loop; it cannot use the page DOM.
• Starting a worker creates setup work, so reuse workers for repeated expensive jobs.
• Structured clone creates independent supported values and becomes more work as the message graph grows.
• Transferables move ownership; an ArrayBuffer sender becomes detached with a byteLength of zero.
• Shared workers coordinate same-origin clients through ports, while worklets run inside focused browser pipelines.

Coming next: SharedArrayBuffer & Atomics, where two agents can intentionally share memory and must coordinate access carefully.