Lesson 0003 · ~12 minutes

Deal-breakers, patterns & hands-on

One skill: run a design-review risk scan on BroadcastChannel — when light pub/sub breaks down, which patterns are safe, and how to verify with two tabs.

← Lesson 2 Checklist Core API Glossary Mission

Win for this lesson

You can reject lock/leader myths, huge-payload buses, and “BC is the database” proposals in under a minute — and green-light logout / theme / invalidate with a two-tab test plan.

1. Wrong tool (reject before more API)

Requirement	Why BC fails	Prefer
One shared WebSocket / engine	No shared process — only messages	SharedWorker
Cross-origin iframe bus	Same-origin (storage key) only	`window.postMessage` / MessageChannel ports
Authoritative durable state	Transient signals; no history	Server, IndexedDB, or other store
Tab-private wizard draft	BC is for fan-out, not isolation storage	`sessionStorage` / memory
Offline shell / fetch policy	Not a network proxy	Service worker + Cache
Safe multi-tab lock / leader	Best-effort notify, not consensus	Server lease or SharedWorker design

Lesson 1 still holds: BC wins for same-origin notify when each peer can react locally (HTML §9.5 points elaborate cases at shared workers).

2. Delivery, order, and “I opened late”

The posting algorithm queues tasks to current destinations that match name + partitioning, then excludes the sender (§9.5). Implications for design reviews:

No replay. A tab that opens after the fact does not receive past messages. Late joiners must read a store or server.
Not a total order log. The spec only partially orders destinations (same agent: creation order; across agents: implementation-defined). Do not model BC as a distributed commit log.
Best-effort peer notify. Closed, suspended, or non-eligible contexts drop out. Design for “most open tabs hear soon,” not “exactly-once global consensus.”

Steal this reject line

“BroadcastChannel is a live bus, not a mailbox. If a tab must know history or hold a lock safely, put authority elsewhere.”

3. Support floor & fallbacks

MDN marks the Broadcast Channel API as Baseline Widely available (across major engines since March 2022) (MDN). Practical floor from caniuse-class tables: Chromium (long), Firefox (long), Safari 15.4+ (macOS and iOS). Internet Explorer never shipped it.

Modern-only product: treat BC as the default multi-tab notify tool.
Long-tail Safari / IE: feature-detect typeof BroadcastChannel === "function"; fallback often means localStorage + storage events (stringly, side-effecty) or “no multi-tab sync.”
Do not invent silent polyfills that pretend locks are safe.

4. Patterns that are safe (and one that isn’t)

Logout

Spec’s motivating example: local logout + postMessage("logout"); peers clear UI. Truth still sits in cookies/session server-side.

Theme / prefs fan-out

Apply locally, persist (localStorage/server), post small { type, value }. Peers apply; late tabs read storage.

Invalidate / refetch

“Orders list dirty” — peers re-fetch or re-read IDB. The message is a hint, not the new list body.

“Soft” presence / “busy” hint

Optional UX: “another tab may be editing.” Never sole safety for writes without server checks.

Unsafe: BC-only lock

Racing tabs both claim “I own the lock” via posts with no durable lease → lost updates. Needs server or a real coordinator process.

Payload discipline (API layer still bites)

Structured clone only — no transfer list (lesson 2). Huge messages cost every peer. Prefer ids and enums. Closed channels throw InvalidStateError. Name typos fail silently.

5. Hands-on checklist (do this once)

Full steps live in integration-checklist.html. Minimum:

Two same-origin tabs, same channel name, log onmessage.
Post from A → B receives; A does not self-echo.
Wrong case in name → silence.
close() then post → InvalidStateError.
Late third tab → no history replay.

6. Practice — reject or green-light

Equal-length options. Design-review voice.

Scenario A

Proposal: “Tabs elect a leader by posting on BroadcastChannel; the leader alone mutates the cart with no server checks.”

Scenario B

After saving an order in Tab A, other open tabs should refresh their orders table from the API.

Scenario C

User toggles theme in Tab A. Tab C opens five minutes later. How should Tab C get the current theme?

Scenario D

Shell on app.example.com and widget iframe on cdn.example.com must share one named notify bus.

Scenario E

Product targets current Chromium, Firefox, and Safari 16+. Need multi-tab logout notify. How do you treat support?

7. What to remember

Reject: shared process needs, cross-origin, BC-as-database, BC-only locks, bulk transfer fantasies.
Accept: logout, theme, invalidate — small signals + local/durable truth.
Live bus: no history replay; partial order only; sender excluded.
Baseline modern browsers OK; Safari 15.4+; feature-detect long tail.

Ask your teacher Sticky points — soft “another tab has focus” UX, polyfill libraries, or a race you saw in prod — ask in chat.

Primary source (read next)

Re-skim HTML §9.5 (simple vs elaborate cases, destination algorithm). Support posture: MDN Broadcast Channel API. Keep the checklist for reviews.