You embed a third-party widget in an iframe and exchange dozens of messages per second in both directions. Why set up a `MessageChannel` and hand one port to the frame instead of calling `window.postMessage` with an origin check on every message?

## The problem with the window message bus `otherWindow.postMessage(data, targetOrigin)` addresses a *window*, and the window's `message` event is a single shared target. Every embedded frame, the opener, and any popup can post to it, so a hardened receiver must, for every message, compare `event.origin` against an allowlist, often compare `event.source` against a specific frame, and then validate the payload. That is correct but it has costs at volume: the checks run on every message, unrelated third-party frames wake your handler, and the security of the channel depends on nobody ever adding a second, sloppier `message` listener to the same page. Nothing in the design lets you say "this conversation is between these two documents". ## What MessageChannel gives you ```js const channel = new MessageChannel(); // channel.port1 and channel.port2 are entangled MessagePort objects ``` The two ports are entangled: a message posted on one is delivered to the other and to nothing else. A `MessagePort` is a transferable object, so you can hand one end to another context. Once the peer holds it, the pair forms a private channel that is not reachable from any third document, even one on the same origin. ## The handshake You still need one window message to bootstrap, because that is the only way to reach a document you have not yet met — and that first exchange is exactly where the origin verification belongs: ```js // Embedder, after the widget announced it is ready const channel = new MessageChannel(); channel.port1.onmessage = (e) => handleFromWidget(e.data); iframe.contentWindow.postMessage({ type: 'connect' }, WIDGET_ORIGIN, [channel.port2]); // Widget window.addEventListener('message', (e) => { if (e.origin !== EMBEDDER_ORIGIN) return; // verify once, here if (e.data?.type !== 'connect') return; const port = e.ports[0]; port.onmessage = (ev) => handleFromHost(ev.data); port.postMessage({ type: 'hello' }); }); ``` The transferred port arrives in `event.ports`. Being transferred means the sending side's reference to `port2` is neutered — you keep `port1` and give away `port2`; you cannot keep both ends usable in one document. After this, the trust argument is structural rather than per-message: the only document that can post on that port is the one you handed it to, at an origin you checked. That does not mean the payload is trustworthy — a compromised peer sends whatever it likes — so message-shape validation stays. What disappears is the per-message question of *who* is talking. ## start() and the queue A port does not deliver until it is started. Assigning `port.onmessage = fn` implicitly calls `start()`. Using `port.addEventListener('message', fn)` does **not** — you must call `port.start()` yourself, and forgetting it is the classic "my channel silently does nothing" bug. Messages posted before the port is started are queued rather than lost, so the peer can send immediately after handover without a race. ## origin and source on port messages A `MessageEvent` delivered through a port has `origin` set to the empty string and `source` set to `null`. This surprises people who copy their window handler over: `if (e.origin !== TRUSTED) return;` rejects every message. There is no origin to report because the port has exactly one counterparty; the identity check happened at handover time. ## Lifetime and teardown A port belongs to the document that holds it. If the iframe navigates or is removed, its end of the channel goes away with that document and your messages simply stop arriving — with no event to tell you. If the connection matters, keep a heartbeat or re-run the handshake on the frame's `load`. Call `port.close()` when you tear the feature down; an unclosed port keeps its peer document reachable and can hold objects alive longer than you expect. Ports can also be transferred onward — you can hand a port to a worker so the widget talks to your worker directly without relaying through the main thread, which is where the pattern starts paying for itself on high-volume traffic. ## When not to bother For a handful of messages — a config push, a resize notification — plain `window.postMessage` with strict checks is simpler and easier for a reviewer to verify. Reach for a channel when the traffic is bidirectional and continuous, when you need several independent conversations with the same peer (one channel per request stream), or when you want a request/response pattern: create a fresh `MessageChannel` per request, send `port2` along with the request, and resolve a promise on the single reply, then close it. That is the shape `ServiceWorker`-adjacent code and RPC wrappers use, and it removes correlation-id bookkeeping entirely.