Liquid DOM: WebGPU liquid glass for React, Three.js and R3F

The problem Liquid DOM solves, and who it is aimed at

Rendering a convincing liquid-glass surface on the web normally means writing WGSL yourself, wiring it into a canvas, and then rebuilding layout by hand because the glass has to track the DOM elements it sits over. Liquid DOM packages that work into layers so you can pick the one that matches the renderer you already own. The README describes the repository as a monorepo for "WebGPU liquid-glass rendering, React bindings, Three.js integration, React Three Fiber integration, and the renderer-agnostic layout engine used by the higher-level APIs".

The audience is narrow and technical. If you are writing a WebGPU scene graph and want glass as a reusable core, or you already render a Three WebGPU scene and want glass composited over it, this is aimed at you. The README's own guidance is to "use the lowest-level package that matches the renderer you own, or the higher-level React packages when you want declarative layout". A team that just wants a frosted CSS panel is not the target, and the browser requirements below explain why.

How the five packages fit together

The split is by integration layer, not by feature. @liquid-dom/layout is independent and carries no renderer dependency; the README describes it as a "renderer-agnostic layout engine" for SwiftUI-style measurement and placement. @liquid-dom/core uses that layout engine for its layout subpath but also exposes a lower-level imperative scene graph, a WebGPU renderer, a reusable glass core, and layout classes.

@liquid-dom/react wraps the layout classes from @liquid-dom/core/layout in React components, so React 19 users describe glass UI declaratively and let LiquidCanvas own the canvas. @liquid-dom/three hosts the reusable WebGPU core inside a Three WebGPU renderer, and @liquid-dom/r3f combines the React and Three packages for React Three Fiber. The dependency direction is one-way: layout feeds core, core feeds react and three, and r3f sits on top of both react and three. That means you can take @liquid-dom/layout without ever pulling in WebGPU code, which is the one package in the set that is not gated on browser graphics support.

Installing Liquid DOM from npm

Installation is per integration target, and the root README says package-specific READMEs list the full install command including peer dependencies. The root examples use pnpm:

pnpm add @liquid-dom/core
pnpm add @liquid-dom/react react react-dom
pnpm add @liquid-dom/three @liquid-dom/core three
pnpm add @liquid-dom/r3f @liquid-dom/react @react-three/fiber react react-dom three
pnpm add @liquid-dom/layout

Pick exactly one line. The React line expects React 19 bindings, and the R3F line pulls in @react-three/fiber alongside react, react-dom and three. If you only want the layout engine, the last line is the whole install.

For repository work the README gives a workspace flow: pnpm install, then pnpm -r build, then per-package tests. The root package.json adds demo scripts that run a package alongside its demo, for example `pnpm dev:minimal`, `pnpm dev:three`, `pnpm dev:three-r3f` and `pnpm dev:three-react`, each filtered to the packages that demo needs. The repository ships demo directories named minimal, blending, showcase, three, three-layout, three-react and three-r3f, so the fastest first look is to run the matching dev script and open the demo, then read that package's README before writing your own scene.

The browser requirements are the real constraint

This is where Liquid DOM stops being a general-purpose library. The README states that the liquid-glass renderer requires WebGPU, and that DOM-backed Html content additionally requires the experimental HTML-in-Canvas API, "currently available only behind Chrome's Canvas Draw Element flag: chrome://flags/#canvas-draw-element". The implementation uses `<canvas layoutsubtree>` and canvas paint events to copy live DOM content into GPU textures.

The practical consequence: the DOM and React packages can build scene graphs in any browser-like environment, but rendering requires a browser exposing navigator.gpu, and rendering DOM-backed content needs the Chrome flag on top of that. Three integrations require Three's WebGPU renderer, not WebGLRenderer. So an existing Three project on WebGLRenderer cannot adopt the three or r3f packages without moving renderers first. There is no fallback path documented for browsers without WebGPU, and the README does not describe a graceful degradation mode. If your users are on Safari or Firefox, or on un-flagged Chrome, this is the wrong tool today, regardless of how the glass looks in the demo.

Where the documentation is thin

The root README is a package map, not an API reference. It tells you which package to install and what each one is for, then defers: "Use the package READMEs for package-level build and test commands." There are no release notes in the repository, and no published version numbers, so pinning a specific version before you start is something you have to check on npm yourself.

Two files at the repository root, ADAPTIVE_BLUR_PERF.md and ADAPTIVE_TINT.md, suggest adaptive blur and adaptive tint are real concerns in the implementation, but the root README does not explain what they do or how to configure them. Treat those as pointers to read in the repository rather than documented features. The release flow is Changesets based, with release:version, release:publish and release:check scripts plus a .changeset directory, so package versions move independently and you should expect the five packages to be versioned separately rather than in lockstep.

A real alternative, and the difference in approach

The closest alternative for React Three Fiber users is the postprocessing ecosystem, where effects are applied as passes over a rendered scene. The difference is architectural. A postprocessing pass operates on the finished frame buffer, so it can blur or distort what was already drawn but it does not know about individual DOM elements and cannot track them.

Liquid DOM instead builds a scene graph and layout model first, then renders glass against it, and for DOM-backed content it copies live DOM into GPU textures through canvas paint events. That is why @liquid-dom/layout exists as a standalone package at all: measurement and placement happen before rendering, in a renderer-agnostic layer. The trade-off is that you are adopting a layout engine and a scene graph, not dropping a pass into an existing pipeline. If your glass only needs to blur whatever is behind it in a Three scene, a postprocessing pass is less machinery. If the glass has to align with DOM elements or with SwiftUI-style layout rules, the pass approach cannot express that, and Liquid DOM's extra layers are the point.

Licence, maintenance and upgrade cost

The repository is MIT licensed, declared both in the LICENSE file and in the root package.json, with the root package marked private. MIT is permissive: you can use, modify and redistribute the packages, and the main obligation is preserving the copyright and licence notice. That is a description of the licence text, not legal advice; check it against your own distribution requirements.

The last push to the default branch was on 2026-09-06, and the repository is not archived, so there is recent activity. The upgrade cost comes from the versioning model rather than from the licence. Because Changesets versions each of the five packages independently, a bump in @liquid-dom/core does not automatically move @liquid-dom/react, @liquid-dom/three or @liquid-dom/r3f, and the r3f package depends on both react and three. Budget for reading changesets per package rather than treating the monorepo as one version, and expect peer dependency ranges on react, react-dom, three and @react-three/fiber to be the thing that breaks first when you upgrade.

Editorial conclusion

Adopt Liquid DOM if you own a WebGPU rendering path and want glass surfaces as a composited layer rather than hand-written shaders, using @liquid-dom/layout alone if you only need SwiftUI-style measurement. Do not adopt it for production web apps that must run in Safari, Firefox or un-flagged Chrome, because DOM-backed Html content requires the experimental HTML-in-Canvas API behind chrome://flags/#canvas-draw-element. Verify first that navigator.gpu is present in your target browser and that your Three setup uses Three's WebGPU renderer, not WebGLRenderer.

Frequently asked questions

Official sources

1. AndrewPrifer/liquid-dom on GitHub
2. Issues
3. License: MIT
4. Project website
5. README