BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Canvas UI Ships 35 HTML-in-Canvas Components That Run WebGL and WebGPU Effects Over Live DOM

Canvas UI Ships 35 HTML-in-Canvas Components That Run WebGL and WebGPU Effects Over Live DOM

Listen to this article -  0:00

Canvas UI, an open source component library from React Bits creator David Haz, has launched as the first library built on the experimental HTML-in-Canvas API, running GPU effects over real, interactive page content.

The library ships 35 components, including pointer-driven fluid, fire, glass lenses, ASCII filters, VHS grain and particle reveals. Every effect has a WebGL build using GLSL and a WebGPU build using WGSL through vgpu, with wrappers for React, Solid, Preact, Vue, Svelte and dependency-free vanilla TypeScript.

Rather than painting a dead bitmap, most components use Chrome's html-in-canvas API to lay out live DOM inside a canvas, capture it with drawElementImage, upload it as a texture and distort it in a shader. Text stays selectable, links stay clickable, and the content stays in the accessibility tree. Components are distributed as source through a shadcn-compatible registry rather than as a package:

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

The full experience needs Chrome with the canvas-draw-element flag, or an origin trial token, which runs from Chrome 148 through 150 and is bound to a single domain. Elsewhere, html-in-canvas effects fall back to a plain GPU overlay or render the wrapped content unchanged, and the 3D object components work everywhere.

Because code is copied into the repository, upgrades mean re-running the install command and reconciling local edits. Switching renderers is mostly replacing the installed file with the -webgpu registry item, which adds vgpu and @webgpu/types. The project also documents that Chrome 150's changes to texElementImage2D and copyElementImageToTexture require no migration, since capture happens through the 2D API and uploads use standard texImage2D or copyExternalImageToTexture.

shadcn called it one of the most impressive registries they have seen, and the Chrome for Developers account said it was good to see html-in-canvas empowering new frameworks. Writing a detailed teardown, Flavio Copes praised the unglamorous engineering: the Liquid component stops its loop with IntersectionObserver when off-screen, honours prefers-reduced-motion, and releases textures, programs and listeners on unmount. His advice was to use one strong effect rather than six, and to avoid dashboards, checkout flows and documentation sites.

On Hacker News, one commenter responded to a demo's banner with scepticism about a Google-only capability:

Use Chrome... and aren't we supposed to reject these technologies that allow Google to Embrace, Extend, Extinguish?
Kudos to the artist in spite of this unfortunately esoteric (wish it weren't) concern

Another user replied:

The standardization process requires implementations before standardization. And the most recent comments on the WHATWG issue are from Jake Archibald (Mozilla) and Anne van Kesteren (Apple). This isn't a unilateral Google project.

Accessibility discussion in the WICG explainer is still open, including how drawable subtrees without updated geometry are exposed.

Paper Shaders offers zero-dependency canvas shaders installed from npm, but they sit behind or around content as texture. React Bits, from the same author, animates DOM directly. Canvas UI is the only option using the page itself as shader input, which is also why it depends on a feature that Safari and Firefox do not implement.

Licensing is MIT plus the Commons Clause, so commercial use is allowed but reselling the components is not. The repository has passed 4,600 stars, and the registry is MCP-ready, letting assistants browse and install components through the shadcn MCP server.

About the Author

Rate this Article

Adoption
Style

BT