Canvas UI: WebGL and WebGPU Effects That Wrap Your Live DOM

The problem Canvas UI targets: effects that do not break the page underneath

Most WebGL effect libraries put a canvas somewhere near your UI and ask you to give up the DOM inside that region. Text becomes an image, links stop being links, and accessibility tooling sees nothing. Canvas UI takes the opposite position. Its components wrap your existing subtree, and the effect renders over content that stays live and interactive. The README states that most components wrap your content, that "the subtree stays live and interactive", and that the effect runs on top.

The mechanism behind that claim is the experimental HTML-in-canvas API. According to the README, most components use it to read and redraw your live DOM, so "the page becomes a texture that fire, fluid, and glass distort in real time". Where that API is unavailable, components fall back to GPU overlays, which the README frames as the reason every visitor gets a working page. That fallback is the honest part of the design: the effect degrades, the content does not.

The audience is narrow and specific. This is for design engineers and frontend teams building marketing pages, portfolios, product landers and experimental interfaces who already live in a shadcn and Tailwind workflow. It is not for teams that need a plain npm package with a semantic version to pin. The README's own framing is "Copy, do not install": source lands in your repository through a shadcn-compatible registry.

How the registry works: source files, not a runtime dependency

The distribution model is the first thing to understand, because it changes everything downstream. There is no @canvas-ui runtime package to import. The shadcn CLI fetches component source and writes it into components/canvasui/ in your project, and the README says that code is "yours to edit".

That choice has real consequences. You can change the shader, delete props, or restructure the component without forking anything, because you already own the file. You also inherit every future bug fix manually: when the upstream component changes, nothing tells you. There is no lockfile entry to bump. The repository itself is a Next.js application (package.json lists next 16.2.10 and react 19.2.4) whose build scripts generate the registry. The dev script runs npm run registry before next dev, and the registry script chains a live-wrappers build and a registry build through Node's --experimental-strip-types flag. In other words, the site you browse at canvasui.dev and the components you copy are produced by the same build pipeline in that repository.

Two renderer builds exist for every effect. The WebGL build is the default: raw WebGL2 and GLSL, with three as the only dependency, and only for the object effects. The WebGPU build renders through vgpu with WGSL shaders, keeps the same props and public API, and installs with a -webgpu suffix on the registry name. Six frameworks are supported: React, Solid, Preact, Vue, Svelte and vanilla.

Installing Canvas UI with the shadcn CLI and rendering a first component

The README's quick start assumes shadcn is already initialised in your project. If it is not, run the init command first, then add a component. The registry name encodes both the component and the framework.

npx shadcn@latest init
npx shadcn@latest add @canvas-ui/liquid-react

After the add command completes, the README says the source lands in components/canvasui/. You should see a Liquid component file there, and it is editable. Swap liquid for any other component name, and react for solid, preact, vue, svelte or vanilla.

The usage pattern wraps your page. The README gives this example, importing from the path the CLI just wrote to:

import { Liquid } from "@/components/canvasui/Liquid";

export default function Page() {
  return (
    <Liquid>
      <YourEntirePage />
    </Liquid>
  );
}

What you should see is your normal page rendering, with the liquid effect distorting it. The content inside the wrapper is not replaced by a canvas snapshot in the supported case; it is read and redrawn.

For the WebGPU build, append the suffix to the registry name. The README gives this exact command:

npx shadcn@latest add @canvas-ui/liquid-react-webgpu

WebGPU builds ship for all six frameworks. The README states they need a browser with WebGPU: Chrome or Edge 113+, Safari 26+ / iOS 26, or Firefox 141+. If WebGPU is missing, the README says the wrapped content renders unchanged. There is also a manual setup path, and the README points to canvasui.dev/docs/installation for it rather than describing it inline.

The HTML-in-canvas dependency is the real constraint

The most interesting capability is also the least portable. The README describes HTML-in-canvas as experimental and links to its Chrome Platform Status entry. Experimental web platform features are gated, and this one is not universally available. The repository's own .env.example carries a NEXT_PUBLIC_HTML_IN_CANVAS_OT_TOKEN variable, described as an "html-in-canvas origin trial token, bound to the production origin". An origin trial is a temporary mechanism: it is tied to a specific origin and to a trial window, not a permanent API guarantee. The README does not state what happens to the DOM-reading path once a trial ends, and it does not document a migration plan.

So the honest reading is that the flagship behaviour, where your live text and links are distorted as a texture, depends on a browser feature that may change or disappear. The fallback to GPU overlays keeps the page working, but a GPU overlay is a different visual result from a DOM-read effect. If your design depends on the text itself warping, you are depending on the experimental path.

There is a second limitation that the README does not address at all: cost. Fluid simulations, shader effects and 3D scenes are GPU work running over a full page. The README does not publish frame-time figures, memory budgets, or guidance on how many wrapped components can coexist on one route. The playground at canvasui.dev/playground is where the README tells you to compare components, and that is the practical way to judge whether a given effect is affordable on your target hardware.

Where Canvas UI is the wrong tool

If you need a dependency you can pin, audit through a lockfile, and upgrade with a single version bump, this is the wrong shape. Copy-in registries move the maintenance burden to you. Every component you add is code you now own, and the README's installation guide is the only documented path back to upstream.

The second wrong fit is a content-heavy application where the effect is decoration rather than the point. Wrapping an entire page in a fluid simulation for a documentation site or a dashboard trades rendering cost for atmosphere, and nothing in the README suggests the components are tuned for that. The components are described as creative components with sensible defaults, not as performance-budgeted primitives.

The third is any project that needs a supported browser matrix with a guarantee. The README states WebGPU version requirements precisely (Chrome/Edge 113+, Safari 26+ / iOS 26, Firefox 141+), which is more than many libraries do, but the HTML-in-canvas path is described as experimental and the README does not enumerate which browsers currently expose it. If you cannot test the fallback path on your own traffic, you do not know which of the two visual results your users get.

Compared with building on three.js or vgpu directly

The obvious alternative is to skip the registry and write the effect yourself against three.js or vgpu, both of which Canvas UI already depends on. That is not a rhetorical comparison: package.json lists three ^0.185.1 and vgpu ^0.3.1 as dependencies of the repository, and the README says the WebGL build uses raw WebGL2 and GLSL with three as the only dependency for the object effects, while the WebGPU build renders through vgpu with WGSL shaders.

The difference in approach is where the work sits. Going direct gives you full control over the render loop, the shader, and the integration with your framework, and it gives you a versioned dependency you can update on your own schedule. What it does not give you is the wrapper layer that keeps your DOM interactive. That wrapper, plus the fallback to GPU overlays, plus six framework builds and two renderer builds per effect, is what the registry is actually selling. Thirty-five components across six frameworks and two renderers is a lot of surface to reproduce by hand.

A second alternative is a canvas-only effect library that renders its own content rather than reading yours. Those are simpler and more predictable, and they are the right choice when the effect is the content rather than a treatment applied to content. Canvas UI's whole premise is the opposite case.

Licence and upgrade cost

The repository's README badge says the licence is "MIT + Commons Clause", and the licence file is LICENSE.md. The GitHub metadata reports the licence as NOASSERTION, meaning the platform's classifier did not recognise it as a standard SPDX identifier. That is consistent with a modified MIT licence: the Commons Clause is an addition, not a standard OSI licence, which is why automated detection fails.

The practical point, without giving legal advice, is that MIT plus Commons Clause is not plain MIT. The Commons Clause restricts selling the software itself. Because Canvas UI distributes source that you copy into your own repository, the question of what counts as "the software" versus "your application" is one you should answer against LICENSE.md with your own counsel before shipping a commercial product built on these components. The README does not discuss commercial use, resale, or attribution requirements.

On upgrades: there is no version number for the components. The repository's package.json version 0.1.0 describes the site, not the registry. No releases were retrieved. The README does not document rollback, changelogs, or how a copied component gets updated when upstream changes. Treat each copied component as a fork from the moment it lands in components/canvasui/.

Editorial conclusion

Canvas UI fits teams already running shadcn and Tailwind who want a shader effect over an interactive page without writing GLSL plumbing. It does not fit anyone who needs a stable, versioned npm dependency, a documented support policy, or a licence that permits reselling the components themselves. Verify three things first: whether your target browsers expose the HTML-in-canvas API or will fall back to the GPU overlay path, whether you want the default WebGL build or the -webgpu registry suffix, and what the Commons Clause in LICENSE.md actually forbids for your product. Because components are copied into components/canvasui/, the upgrade path is re-running the add command per component, not bumping a version in package.json.

Frequently asked questions

Official sources

1. DavidHDev/canvas-ui on GitHub
2. Issues
3. Project website
4. README