Browser demo limits

What the demos are

Every demo on this site is the real component, compiled to WebAssembly and drawn by the same code a native application runs. They are not videos, screenshots, or a re-implemented preview. One binary carries all 37 stories, which is why a demo starts when it scrolls into view rather than on page load.

A demo stops when it is more than a viewport away, and at most three run at once. Each one is a WebAssembly instance with its own heap and a GPU surface, and a long page of them left running would cost more than the page is worth.

They need WebGPU

There is no WebGL fallback. Without WebGPU the site shows a still frame captured from the real component and downloads nothing — a seventeen-megabyte binary that cannot be used is worse than an honest picture.

They follow your motion preference

A demo reads prefers-reduced-motion and tells the running gallery, so a reader who has asked their machine for stillness gets the same answer here as in a native build. GPUI takes that preference from the platform, and the web platform has none — without this every demo on the site shimmered at them.

Adding motion=reduced or motion=full to a demo’s address pins it either way, which is how you can see what reduced motion does to a component without changing a system setting to find out.

Keyboard in the browser

Keyboard input works in the live demos: Tab and Shift+Tab move focus, arrow keys reach the components that use them, and text selection and Ctrl+C behave. Earlier builds froze a demo on the first key press because GPUI’s profiler — whose action path reads a clock that wasm32-unknown-unknown does not implement — was compiled into everything. Upstream now scopes that feature to the one crate that uses it, so the web build no longer contains the failing path at all.

The native build remains the runtime the keyboard, clipboard, and accessibility test suites actually exercise; treat the browser as a faithful demonstration rather than the verified surface.

The native runtime decides

Where the browser and a native build disagree, the native build is the one that has been verified: it is the runtime the test suite exercises and the one the components are designed for. The demos exist so you can see a component before depending on it, not to define what it does.