canvas-ui: WebGL and WebGPU Effects Over Live, Interactive HTML

The Technical Problem canvas-ui Solves

Canvas overlays have a fundamental problem: they obscure the content they float over. A canvas element positioned above a web page catches pointer events, making links and buttons underneath unresponsive. canvas-ui addresses this through the experimental HTML-in-canvas API, which reads and redraws the live DOM inside the canvas. With this approach, the browser renders the original HTML as a canvas texture and then applies the shader effect to that texture. The page beneath remains a functioning DOM: text stays selectable, links stay clickable, forms stay submittable. Where the HTML-in-canvas API is not supported, components fall back to GPU overlays, preserving the visual effect at the cost of DOM interactivity in those cases. The README describes both rendering paths explicitly. The HTML-in-canvas origin trial token is required for the production environment, and the .env.example documents a NEXT_PUBLIC_HTML_IN_CANVAS_OT_TOKEN variable for that purpose.

Installing a Component via the shadcn Registry

canvas-ui distributes components through a shadcn-compatible registry rather than a traditional npm package. Instead of adding a dependency to node_modules, each component's source lands directly in your project's components/canvasui/ directory. The README describes the install flow:

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

If you have not initialized shadcn in your project:

npx shadcn@latest init

Then import and use the component in your React code:

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

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

Most components wrap your content. The child subtree stays live and interactive; the canvas effect runs on top. The README notes that source landing in your repo means the code is yours to edit, which is a meaningful difference from a black-box npm dependency. Swap 'liquid' for any component name from the catalog at canvasui.dev/components, and swap 'react' for the framework variant you need. A live playground at canvasui.dev/playground lets you compare all 35 components side by side before adding any to your project.

Framework Support: React, Vue, Svelte, Solid, Preact, and Vanilla

Every component in canvas-ui ships for six targets: React, Solid, Preact, Vue, Svelte, and vanilla JavaScript. The registry suffix in the install command determines which variant you get: swap the word 'react' for 'solid', 'preact', 'vue', 'svelte', or 'vanilla'. The same props and public API apply across all six. This means a team using Vue or Svelte gets the same effect without rewriting their component tree in React. The 35 components available at the time of the last push include effects in four categories: fluid and motion effects (Liquid, Ripple, Cloth, Droplets, Bubble, Displacement), fire and energy effects, glass and light effects (Glass), and text and object effects (Shatter, Force Field, Decrypt Reveal). All components and both renderer variants can be compared in the playground at canvasui.dev/playground before adding any code to a project.

WebGL and WebGPU Builds

Each component ships in two renderer builds. The default WebGL build uses raw WebGL2 and GLSL shaders, with Three.js as a dependency only for the object effects. The WebGPU build uses vgpu with WGSL shaders and installs from the registry with a -webgpu suffix:

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

The two builds share the same props and public API, so switching renderers requires only a different import path. The README specifies that WebGPU needs Chrome or Edge 113 or later, Safari 26 or later, iOS 26 or later, or Firefox 141 or later. If a visitor's browser lacks WebGPU support, the component renders the wrapped content unchanged with no error. Details are in the rendering guide at canvasui.dev/docs/rendering. For teams that need to support older browsers, the WebGL build is the safer default.

MCP Integration and the Zero-Config Design

The README lists MCP readiness as a feature, stating that an AI assistant can find and install components through the MCP protocol. Each component is described as self-contained with sensible defaults and typed props. The zero-config claim means that wrapping content in a component like Liquid produces a working effect without any additional configuration. Optional props are available for customizing behavior, but the README frames them as adjustments rather than requirements.

The package.json shows a layered set of scripts for developing and deploying the site. Running `npm run dev` first builds the component registry and then starts the Next.js development server. The `registry` script calls `live` (which builds framework wrapper files) and then `build-registry.mts` to generate the shadcn-compatible registry that clients fetch components from. Before each production build, `prebuild` runs the registry step automatically, ensuring the published registry always reflects the current component code. The `preflight` script validates the deployment configuration before any deploy or upload command proceeds, catching missing Cloudflare environment values early. The .env.example documents two build-time values: the Cloudflare Turnstile site key for the newsletter signup form (required when TURNSTILE_ENABLED is set in wrangler.jsonc) and the HTML-in-canvas origin trial token for the production origin. The README specifies that the deploy preflight script rejects Cloudflare's test key, which means the Turnstile integration in production requires obtaining a real site key from Cloudflare.

License and Commercial Use Restrictions

canvas-ui is licensed under MIT plus Commons Clause. The MIT license permits free use, modification, and redistribution. The Commons Clause adds a specific restriction: the license does not grant the right to sell the software itself. Practically, this means you may use canvas-ui to build any product or service, including commercial ones, as long as you are not selling the canvas-ui components themselves as a product or as part of a component marketplace. Building a competing component library based on the source code would likely violate the Commons Clause. The restriction is common in open-source component libraries where the authors want to allow broad use while preventing direct commercialization of the components as a standalone product.

Practical Limits: Performance and Browser Constraints

Running WebGL or WebGPU shaders continuously over a page has a real GPU cost. On low-end devices or devices with integrated graphics, effects like Liquid or Fire may reduce frame rates in other parts of the page or drain battery faster. The README does not document performance benchmarks or recommended hardware minimums. The HTML-in-canvas API that enables DOM interactivity through the canvas is described as experimental by the README itself, which links to the Chrome Status page for the feature. This means browser support is not guaranteed to remain stable or consistent across browser updates. Teams building production sites with these effects should test the fallback path (GPU overlays without DOM interactivity) on a representative set of devices before deploying. The shadcn-based distribution model also means there is no version-pinned npm package to update with a single command; when the canvas-ui registry updates a component, you need to re-add it to pick up the new source. For teams using a component frequently and relying on its behavior staying stable, this requires discipline about when and whether to pull upstream changes.

Editorial conclusion

canvas-ui suits front-end developers building marketing pages, portfolios, or product landing pages where a liquid, glass, or shatter effect would differentiate the design. It is not appropriate for application UIs where performance consistency matters across low-end devices, or for teams that cannot accept the MIT plus Commons Clause license, which prohibits building a competing component library or marketplace with the source code. Before adopting it, verify that your target browsers support the renderer you plan to use: WebGL2 is broadly available, but WebGPU requires Chrome or Edge 113+, Safari 26+, or Firefox 141+.

Frequently asked questions

Official sources

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