Drive a second monitor from your web app.

The gap

Everyone already works this way. The web just can't. ​

Radiology worklists, trading desks, DAWs, IDEs — every field that works on two monitors solved this decades ago in native code. Web apps never got the plumbing, so people improvise:

Try it here

A working demo, in this page ​

This is the real playground running in an iframe, pinned to split mode so both surfaces fit. Click a row and the inspector follows. On two monitors, that right-hand pane is a separate window on your second screen — same component, same state, no code change.

Install

One package, four entry points ​

npm install dualscreen
# pnpm add dualscreen
# yarn add dualscreen
# bun add dualscreen

Prefer smaller graphs? Install the scoped packages individually.

Implementation

The whole integration, in four steps ​

There is no second bundle to build, no second route table to maintain, and nothing to deploy. Both windows run the same component tree.

import { DualScreen } from 'dualscreen/react'

export function App() {
  return (
    <DualScreen channel="my-app">
      {/* everything else */}
    </DualScreen>
  )
}

<DualScreen channel="my-app">
  <DualScreen.Main>
    <ExperimentTable />
  </DualScreen.Main>

  <DualScreen.Surface name="inspector">
    <ExperimentDetail />
  </DualScreen.Surface>
</DualScreen>

import { useShared } from 'dualscreen/react'

function ExperimentTable() {
  const [selected, setSelected] = useShared<string | null>('selected', null)

  return rows.map((row) => (
    <tr key={row.id}
        aria-selected={row.id === selected}
        onClick={() => setSelected(row.id)}>
      <td>{row.name}</td>
    </tr>
  ))
}

function ExperimentDetail() {
  const [selected] = useShared<string | null>('selected', null)
  // Resolve the id against your own cache — React Query, SWR, anything.
  const { data } = useQuery({ queryKey: ['row', selected], queryFn: fetchRow })
  return <Detail data={data} />
}

import { useSurface } from 'dualscreen/react'

function Toolbar() {
  const inspector = useSurface('inspector')

  return (
    <button onClick={() => inspector.open()}>
      {inspector.isConnected ? 'Inspector open' : 'Open on second screen'}
    </button>
  )
}

Full walkthrough →

The core idea

A surface is a route ​

This is the reframing that makes adoption cheap. In a single-page app, "what's on screen" already is a route plus params — so a second window doesn't need to be a new app. It's the same app, at the same URL, told to render a different named surface.

/dashboard              → surface "main"
/dashboard?ds=inspector → surface "inspector"

The rule that matters

Ids, not payloads ​

BroadcastChannel uses structured clone, which copies. Broadcasting a 200 MB matrix doesn't pass a reference — it serialises and deserialises the whole thing into every connected window, blocking the main thread on both ends. This is the single rule that decides whether a cross-window library survives contact with real data.

setSelected('EXP-102')

setSelected(rowsForExperiment102)

The rule generalises: send the smallest thing that describes the selection. The linked-brushing demo ships a brush over 400 points as a rectangle in data space — four numbers — so cost never grows with the selection, and the receiving window can apply it to entirely different axes.

Read more →

What you get

Built for the parts that actually go wrong ​

Demos

Three patterns, running live ​

Each opens the full playground. Every one degrades in front of you — shrink to one monitor and it becomes a split pane.

API

The whole surface, on one screen ​

import { createLink } from 'dualscreen'

const link = createLink({ channel: 'my-app' })

link.set('selected', 'EXP-102')
link.subscribeKey('selected', (id) => render(id))
link.send('rerun', { force: true })
link.command('rerun', (args, from) => rerun(args))

await link.whenReady()
link.close()

Browser support

An honest account ​

Two different things degrade differently, and conflating them is how libraries in this space oversell themselves. The API that places a window on a chosen monitor is Window Management, and it is Chromium-only. We don't paper over that — we confine the damage.

The degradation ladder

Your code does not change between rungs. open() is the same call; <DualScreen.Surface> is the same JSX.

Prior art

Where this differs ​

The transport layer is genuinely commoditised — BroadcastChannel has been baseline for years. What was missing everywhere else is the combination.

Deliberately not a CRDT. dualscreen targets the shape where one window drives and the others follow, and last-writer-wins is the honest fit. If you need genuine concurrent editing, put Yjs on top and use dualscreen as the transport — the Transport interface is public for exactly that.

Security

The trust boundary is the origin ​

BroadcastChannel is scoped to an origin, not to your app. Any script on the page — an analytics tag, an embedded widget, a compromised dependency — can join a channel and read or write shared state. The data was always reachable; what changes is how convenient it is to collect. So put no secrets in shared state, and treat everything arriving from another window as untrusted input.