Transferable objects
Slap yourself if
You think transferables are just an optimization for postMessage or assume the sender keeps using the object afterward.
Why this exists
Because teams unknowingly copy megabytes across threads or, worse, crash logic by accessing data they already transferred away.
Mental model
Transferables move ownership, not data. After transfer, the sender loses access. This is zero-copy by invalidation, not sharing.
- An object marked transferable is detached from the sender.
- Ownership of the underlying memory moves to the receiver.
- The sender’s reference becomes neutered and unusable.
- No byte-level copy occurs during the transfer.
- Accessing ArrayBuffers after transfer.
- Assuming transfer implies shared memory.
- Mixing transferables with structured cloning assumptions.
- Using transferables without clear ownership protocols.
Transferable objects move ownership of underlying memory between threads without copying, invalidating the sender’s reference.
- Calls it shared memory.
- Assumes post-transfer reads still work.
- Focuses only on speed.
- Cannot explain neutering.
Deep dive
Requires Pro
Premium deep dives include more internals, more scars.