Lesson 0001 · ~10 minutes

When BroadcastChannel fits (and when it doesn’t)

One skill: place BroadcastChannel on the multi-tab tools spectrum and pick it only when the hard problem is same-origin pub/sub notify — not a shared process, not tab-private storage, not network control.

Glossary Resources Mission

Win for this lesson

After the quiz, you can defend “BroadcastChannel yes / no” in a design review without wiring two tabs yet — and without spinning up a SharedWorker for a logout ping.

1. The problem BroadcastChannel solves

Same-origin tabs (and workers) often need a cheap way to say: “hey, something happened over here.” The HTML Standard gives the classic example: the user logs out in one tab; other tabs should notice and clear their UI.

BroadcastChannel is a named channel on one origin. Any eligible window or worker that opens the same name can postMessage; every other open channel with that name gets a message event. That is pub/sub notify — not shared memory, not a coordinator process.

You already met this row on the Web Workers multi-tab map (lesson 5): light “tell other tabs X.” This track owns the judgment and, next, the API.

2. Not a SharedWorker, and not a database

Two confusions that cause bad design reviews:

Not “SharedWorker lite.” The HTML Standard is explicit: for elaborate multi-tab work — locking shared state, one WebSocket shared by many clients, heavy resource sync — prefer a SharedWorker. BroadcastChannel exists for simple cases where a shared worker would be unreasonable overhead (§9.5). Mental model: notify vs shared process.
Not a store of record. Messages are transient signals. They do not replace the server, IndexedDB, or even localStorage as durable state. After “theme changed” or “cache stale,” each tab still applies local UI or re-reads a real source of truth.

Also not: sessionStorage (tab-isolated sticky notes), dedicated worker postMessage (one page ↔ its worker, not multi-tab fan-out by default), or service worker clients messaging as your default theme bus.

3. Multi-tab tools spectrum (BroadcastChannel highlighted)

Same family of choices as Workers lesson 5 — spotlight on the notify row.

Dedicated worker

One page needs CPU offload. Not multi-tab fan-out by default (each tab can spawn its own).

BroadcastChannel

Same-origin contexts need pub/sub messages only — logout, theme, “refetch.” No shared memory, no single coordinator process. Lightest “tell other tabs X.”

localStorage + StorageEvent

Legacy/cross-tab notify with storage side effects. Works as a crude bus; prefer BroadcastChannel when you mean messaging.

sessionStorage

Tab-private string map. Survives reload in that tab; other tabs do not share it — not a multi-tab bus.

SharedWorker

One in-memory coordinator: single socket, shared derived state, multi-window engine. Ports and lifetime to manage.

Service worker clients

Network proxy, offline, push, claim — control plane. Different job from “tab A notified tab B.”

Default rule (steal this)

If the hard part is “other same-origin tabs should hear a short signal and react locally”, start with BroadcastChannel. If the hard part is “one process must own a scarce resource or hold shared in-memory state”, design a SharedWorker. If the hard part is “offline shell / fetch policy / push”, that is a service worker. If you only need state in this tab, use sessionStorage or memory — not a bus.

Signal	Leans BroadcastChannel	Leans away
Job	Notify peers; each tab handles itself	One socket, one lock, one engine for all tabs
Origin	Exact same origin (scheme/host/port)	Cross-origin iframes or “same site” loosely
Payload	Small structured signals / IDs / enums	Huge blobs, binary pipelines, transfer ownership
Truth	Signal that something changed elsewhere	Authoritative durable state for the product
Classic fits	Multi-tab logout, theme/settings fan-out, “invalidate list N”	Shared market feed socket, multi-window map core, offline shell

FE integration difficulty (honest preview)

new BroadcastChannel('auth') is easy. What bites later: sender does not hear itself (run local logout UI too), closed channel posts throw, structured clone limits (no transfer list), and treating a notify as if every tab kept perfect ordered history. We’ll drill the API next. Today: know the job so you don’t oversell “just broadcast everything.”

4. Practice — pick the multi-tab tool

Choose the best default. Equal-length options so formatting doesn’t hint. Feedback is immediate.

Scenario A

When the user logs out in one tab, other same-origin tabs should clear session UI within a second.

Scenario B

Trading dashboard: up to 8 tabs open; product wants one WebSocket to the market feed, all tabs update.

Scenario C

Checkout wizard: 4 steps in one tab. A second parallel checkout tab must not overwrite this flow; reload in this tab should restore step.

Scenario D

Settings: user toggles light/dark in one tab; other open same-origin tabs should update chrome immediately. Preference may also be saved to localStorage or the server.

Scenario E

PWA: first visit should install a shell so later visits work offline with a network-first API strategy.

5. What to remember

BroadcastChannel = same origin + same channel name pub/sub for windows and workers.
Use it for notify (logout, theme, invalidate) — not as a SharedWorker substitute or a database.
Spec default: simple multi-tab signals → BC; elaborate shared resources → SharedWorker.
Prefer sessionStorage for tab-private state; SW for network/offline; never treat a message as the sole source of truth.

Ask your teacher Anything fuzzy — Safari support, storage-event hacks you’ve seen, a multi-tab bug on your team — ask in chat. Follow-up questions are part of the method, not a distraction.

Primary source (read next)

WHATWG HTML — §9.5 Broadcasting to other browsing contexts. Best primary for this lesson’s job split (simple notify vs SharedWorker) and the logout example. Skim MDN — BroadcastChannel for the interface surface you’ll use next lesson.