Worker Message Passing

## The only channel a worker has A dedicated Web Worker runs on its own thread with its own global scope. It cannot reach into the page's variables and the page cannot reach into its. The single sanctioned channel between them is message passing: the page holds a `Worker` object and calls `worker.postMessage(value)`; the worker calls `self.postMessage(value)` back. Each side listens for a `message` event and reads the payload from the event's `data` property. ```js // page const worker = new Worker('/echo.worker.js'); worker.onmessage = (event) => console.log(event.data); worker.postMessage({ count: 1 }); // inside echo.worker.js self.onmessage = (event) => self.postMessage(event.data.count + 1); ``` Note the shape: the handler receives an **event object**, not the payload. Reading the first argument as if it were the message itself (`worker.onmessage = (msg) => msg.count`) is the single most common beginner bug here. ## Copy, not reference When you call `postMessage`, the browser does not hand the receiving thread a pointer. It runs the *structured clone* algorithm: it walks the value you passed and builds an independent reconstruction of it for the other side. That reconstruction is what lands in `event.data`. Two things follow immediately. First, **the copy is taken at the call**, synchronously, before `postMessage` returns. Anything you do to the original afterwards is invisible to the receiver: ```js const payload = { count: 1 }; worker.postMessage(payload); payload.count = 2; // too late — the clone already recorded 1 ``` Second, **the two graphs are permanently disconnected**. The worker can mutate its copy freely; the page will never see it. There is no live binding, no proxying, no write-back. If both sides need to agree on evolving state, they have to exchange messages about it, or one side has to be the owner and the other has to ask. ## What survives inside one message Within a *single* message the clone is faithful about the shape of the graph, not just its leaves. If the same object appears twice inside the value you post, the receiver also gets it twice as one shared object; cyclic structures are reproduced as cycles rather than causing infinite recursion. That is why structured clone exists at all instead of the browser simply calling `JSON.stringify` for you. What it does **not** do is preserve identity *across* messages. Post the same object twice and the receiver gets two unrelated copies. Post a value and then post it again after mutating it, and the receiver sees two snapshots, in order. Not every value can be cloned; posting something the algorithm cannot reconstruct throws a `DataCloneError` at the `postMessage` call rather than failing silently later. Symmetrically, if a message arrives that the receiver cannot deserialize, the receiver gets a `messageerror` event instead of `message` — worth wiring up in production code, because otherwise such a failure is completely invisible. ## Delivery is a task, not a call `postMessage` returns as soon as the copy is made. The message is then queued on the receiving side and dispatched as a task on that thread's event loop. So the receiver's handler runs some time later, and — importantly — only when the receiving thread is free to run a task. If the worker is in the middle of a long synchronous computation, your message sits in its queue until that computation finishes. Message passing does not interrupt anything. Order is preserved per channel: messages posted from one side arrive in the order they were posted. There is no ordering guarantee *between* different channels, and no acknowledgement — `postMessage` is fire-and-forget, so if you need to know that the other side received or processed something, that has to be an explicit reply message you design yourself. ## Designing around it Because every exchange is a copy, the interesting design question stops being "how do I share this object" and becomes "who owns this state". The usual answer is that the worker owns the expensive thing — a parsed index, a loaded dataset, an initialized engine — and the page sends small instructions and receives small results. The moment you find yourself shipping the same large structure back and forth so both sides can "see" it, you have chosen the wrong owner, and you will pay for the copy on every message.