Reference

Messaging, clone & transfer

The channel tax between main thread and workers. Normative base: WHATWG structured data.

Default: structured clone (copy)

worker.postMessage(value);
// value is serialized then deserialized on the other side
// each realm gets its own copy — not the same object

Used by postMessage, structuredClone(), IndexedDB, etc. ( MDN).
Handles cycles, Map/Set, ArrayBuffer, plain objects, many web types.
Does not clone: functions, DOM nodes → DataCloneError.
Prototype chains, getters/setters metadata, private class fields not preserved as “live” object identity.

Transfer: move ownership (zero-copy for buffers)

// Transfer the underlying ArrayBuffer — sender loses it
worker.postMessage(u8, [u8.buffer]);
// after this, u8.byteLength === 0 on the sender (detached)

Transfer list is the second arg (or { transfer: [...] }).
Resource must also appear in the message payload, or it detaches with nowhere to land (MDN transferable objects).
Typed arrays are cloneable; their .buffer is transferable — put the buffer in the transfer list.
Common transferables: ArrayBuffer, MessagePort, ImageBitmap, OffscreenCanvas, streams, …

Cost rules of thumb (Surma, measure in your app)

Rough payload	Design take
≤ ~10 KiB	Low risk even near frame budget; fine for frequent UI updates
≤ ~100 KiB	Usually OK for interaction budget (~100ms) even on slow devices
≫ 100 KiB or high frequency	Design for patches, chunking, or transfer — don’t clone whole state every tick

Source framing: Is postMessage slow? — rules of thumb, not laws. Serialize blocks sender; deserialize blocks receiver.

Architecture escapes when clone hurts

Patches — send diffs, not full state (Immer-style patchsets).
Chunking — stream partial results so UI can paint.
Transfer — move large binary with ArrayBuffer ownership.
SharedArrayBuffer — true shared memory + Atomics; COOP/COEP isolation required in modern browsers; advanced / later.