Cross-Context Communication

The Routing Problem

You have three workers: one parsing CSV data, one running statistical analysis, one generating a chart. The analysis worker needs data from the parser. The chart worker needs results from the analysis worker. How do you wire this up?

// The naive approach: route everything through the main thread
const parser = new Worker('/workers/parser.js');
const analyzer = new Worker('/workers/analyzer.js');
const charter = new Worker('/workers/charter.js');

parser.onmessage = (e) => {
  if (e.data.type === 'PARSED') {
    analyzer.postMessage(e.data.records); // Main thread as relay
  }
};

analyzer.onmessage = (e) => {
  if (e.data.type === 'ANALYZED') {
    charter.postMessage(e.data.stats); // Main thread as relay again
  }
};

Every message passes through the main thread — serialized, deserialized, re-serialized, re-deserialized. The main thread is a bottleneck relay station doing zero useful work. For a 10MB dataset, you're paying the structured clone cost four times instead of two.

There's a better way. MessageChannel lets workers talk directly to each other, bypassing the main thread entirely.

MessageChannel: Direct Worker-to-Worker Pipes

MessageChannel creates a pair of entangled MessagePort objects. Send on one, receive on the other. The critical insight: MessagePort is transferable, so you can send one port to a worker and the other port to a different worker — establishing a direct communication link:

// main.js — set up the pipe, then step out of the way
const parser = new Worker('/workers/parser.js', { type: 'module' });
const analyzer = new Worker('/workers/analyzer.js', { type: 'module' });

const channel = new MessageChannel();

// Transfer port1 to parser, port2 to analyzer
parser.postMessage({ type: 'CONNECT', port: channel.port1 }, [channel.port1]);
analyzer.postMessage({ type: 'CONNECT', port: channel.port2 }, [channel.port2]);

// Now parser and analyzer can talk directly — main thread is not involved

// parser.js
let analyzerPort = null;

self.onmessage = (event) => {
  if (event.data.type === 'CONNECT') {
    analyzerPort = event.data.port;
    return;
  }
  if (event.data.type === 'PARSE') {
    const records = parseCSV(event.data.csv);
    analyzerPort.postMessage(records); // Direct to analyzer — skips main thread
  }
};

// analyzer.js
let dataPort = null;

self.onmessage = (event) => {
  if (event.data.type === 'CONNECT') {
    dataPort = event.data.port;
    dataPort.onmessage = (msg) => {
      const stats = analyze(msg.data);
      self.postMessage({ type: 'RESULTS', stats });
    };
    return;
  }
};

Building a Worker Pipeline

With MessageChannel, you can build multi-stage processing pipelines where each stage is a separate worker:

// main.js — wire up a three-stage pipeline
function createPipeline(stages) {
  const workers = stages.map(
    (url) => new Worker(url, { type: 'module' })
  );

  for (let i = 0; i < workers.length - 1; i++) {
    const channel = new MessageChannel();
    workers[i].postMessage(
      { type: 'SET_OUTPUT', port: channel.port1 },
      [channel.port1]
    );
    workers[i + 1].postMessage(
      { type: 'SET_INPUT', port: channel.port2 },
      [channel.port2]
    );
  }

  return {
    input: workers[0],
    output: workers[workers.length - 1],
    terminate: () => workers.forEach((w) => w.terminate()),
  };
}

const pipeline = createPipeline([
  '/workers/parse.js',
  '/workers/transform.js',
  '/workers/aggregate.js',
]);

pipeline.output.onmessage = (e) => {
  renderResults(e.data);
};

pipeline.input.postMessage({ csv: rawData });

Each worker in the pipeline only knows about its input port and output port. The main thread sets up the wiring once and then only interacts with the first and last stages.

BroadcastChannel: One-to-Many Messaging

BroadcastChannel is a publish-subscribe system scoped to a channel name. Every context (tab, worker, iframe) that creates a BroadcastChannel with the same name receives every message:

// In any context — main thread, worker, another tab
const channel = new BroadcastChannel('app-state');

// Send to all subscribers
channel.postMessage({ type: 'THEME_CHANGED', theme: 'dark' });

// Receive from any sender
channel.onmessage = (event) => {
  if (event.data.type === 'THEME_CHANGED') {
    applyTheme(event.data.theme);
  }
};

// Stop receiving
channel.close();

Key differences from MessageChannel:

SharedWorker: One Worker, Multiple Clients

A SharedWorker is a single worker instance shared across all same-origin tabs, iframes, and other contexts. Unlike a dedicated worker (one per creator), a SharedWorker maintains state that is accessible from any connected context:

// Any tab can connect to the same SharedWorker
const shared = new SharedWorker('/workers/shared-state.js', { type: 'module' });

shared.port.onmessage = (event) => {
  console.log('Received:', event.data);
};

shared.port.postMessage({ type: 'GET_STATE' });

// shared-state.js — the SharedWorker
const connections = new Set();
let sharedState = { count: 0 };

self.onconnect = (event) => {
  const port = event.ports[0];
  connections.add(port);

  port.onmessage = (msg) => {
    if (msg.data.type === 'GET_STATE') {
      port.postMessage(sharedState);
    }
    if (msg.data.type === 'INCREMENT') {
      sharedState.count++;
      for (const conn of connections) {
        conn.postMessage(sharedState);
      }
    }
  };

  port.start();
};

SharedWorker use cases:

• WebSocket connection sharing — one WebSocket across all tabs instead of one per tab
• Cache coordination — shared in-memory cache so each tab doesn't fetch independently
• Cross-tab state — synchronized state without localStorage polling
• Connection pooling — shared database or API connections

Service Worker Messaging

Service Workers intercept network requests, but they can also serve as a message relay between the main thread and other contexts:

// Main thread to Service Worker
navigator.serviceWorker.controller?.postMessage({
  type: 'CACHE_UPDATE',
  urls: ['/api/data'],
});

// Service Worker: listen for messages
self.addEventListener('message', (event) => {
  if (event.data.type === 'CACHE_UPDATE') {
    event.waitUntil(updateCache(event.data.urls));
  }
});

// Service Worker to ALL clients (tabs)
self.addEventListener('message', (event) => {
  if (event.data.type === 'BROADCAST') {
    self.clients.matchAll().then((clients) => {
      for (const client of clients) {
        client.postMessage(event.data.payload);
      }
    });
  }
});

Service Workers are powerful for cross-tab messaging because they have access to self.clients — a list of all controlled pages. But they have a different lifecycle (install/activate/fetch) and are not suitable for CPU-intensive work.

Choosing the Right Channel

Need direct worker-to-worker communication?     → MessageChannel
Need to broadcast to all tabs/workers?           → BroadcastChannel
Need shared state across tabs?                   → SharedWorker (or BroadcastChannel + localStorage for Safari)
Need to coordinate cache/network across tabs?    → Service Worker messaging
Need bidirectional communication with one worker? → postMessage (simplest)

Challenge: Cross-Tab Notification System

// Build a notification system where:
// 1. Any tab can send a notification
// 2. All OTHER tabs display the notification (sender does not)
// 3. Notifications include a unique ID, message, and timestamp
// 4. Each tab tracks which notifications it has seen (no duplicates)
// 5. Works in Safari (no SharedWorker)
//
// API:
// notify('New comment on your post')  — sends to all other tabs
// onNotification(callback)            — registers a listener
//
// Hint: BroadcastChannel + tab ID for sender filtering

Key Rules