随着WebGPU技术主导视觉创新浪潮，浏览器渲染格局与Canvas UI组件引发广泛关注。Canvas UI由React Bits团队推出，以实验性HTML-in-Canvas API为核心，融合35项可交互特效，覆盖流体、VHS颗粒等多样化视觉方案，分别提供WebGL与WebGPU技术版本，兼容主流框架且支持原生TypeScript，同时以注册表形式分发源码，为开发者提供低成本落地路径。其核心优势在于突破静态位图限制，在Canvas中实时渲染DOM并捕获内容，实现多格式内容表达，覆盖无障碍与交互场景。在实际应用中，需通过专项环境配置与版本适配获取最佳体验，其中部分特性仅限特定浏览器运行，且需关注技术迭代带来的适配要求。当前项目凭借丰富的技术架构与生态兼容，已积累超4600 Star，其组件注册表更支持MCP服务，为智能化开发提供支撑。技术层面，项目通过标准扩展机制降低依赖复杂度，兼顾功能完善性与稳定性，为浏览器渲染创新提供了可复制的参考范式。
--91likeyou---
npx shadcn@latest add @canvas-ui/liquid-react
要获得完整体验，需要在 Chrome 中启用 canvas-draw-element 标志，或者使用一个源试用令牌。该源试用从 Chrome 148 持续到 Chrome 150，并且令牌只能绑定到一个域名。在其他环境中，html-in-canvas 特效会回退为普通 GPU 叠加层，或者保持被包裹内容的原样渲染；3D 对象组件则可以在所有环境中运行。
由于代码会被直接复制到项目仓库中，升级时需要重新运行安装命令，并处理本地修改。切换渲染器通常只需将已安装的文件替换为注册表中带有 -webgpu 后缀的版本，同时添加 vgpu 和 @webgpu/types。项目文档还指出，Chrome 150 对 texElementImage2D 和 copyElementImageToTexture 的修改不需要迁移，因为内容捕获通过 2D API 完成，纹理上传则使用标准的 texImage2D 或 copyExternalImageToTexture。
shadcn 称这是他们见过的最令人印象深刻的注册表之一，Chrome for Developers 账号也表示，很高兴看到 html-in-canvas 为新框架赋能。Flavio Copes 在一篇详细拆解文章中称赞了那些并不华丽但十分扎实的工程实现：Liquid 组件离开屏幕可视区域时，会通过 IntersectionObserver 停止动画循环；它会遵循 prefers-reduced-motion 设置，并在组件卸载时释放纹理、程序和事件监听器。他建议使用一个足够亮眼的特效，而不是同时堆上六个，并避免在仪表盘、结账流程和文档网站中使用这些效果。
在 Hacker News 上，一名评论者看到演示页面中的提示横幅后，对这种仅限 Google 浏览器使用的能力表示怀疑：
使用 Chrome……但我们不是应该抵制这种可能让 Google“拥抱、扩展再消灭”其他技术的做法吗？
尽管有这种遗憾而又冷门的担忧——真希望它不是冷门问题——还是要向作者致敬。
另一名用户回应：
标准化流程要求先有实现，之后才能制定标准。WHATWG 相关议题中最近的评论分别来自 Jake Archibald（Mozilla）和 Anne van Kesteren（Apple）。这不是 Google 单方面推动的项目。
WICG 说明文档中关于无障碍访问的讨论仍在继续，其中包括如何暴露几何信息尚未更新的可绘制子树。
Paper Shaders 提供从 npm 安装的零依赖 Canvas 着色器，但这些着色器只能以纹理形式位于内容后方或周围。同一作者开发的 React Bits 则直接为 DOM 添加动画。Canvas UI 是唯一将页面本身作为着色器输入的方案，这也正是它依赖 Safari 和 Firefox 尚未实现的功能的原因。
该项目采用 MIT 许可证加 Commons Clause，允许商业使用，但不允许转售这些组件。代码仓库的 Star 数已经超过 4600，组件注册表也已支持 MCP，允许智能助手通过 shadcn MCP 服务器浏览并安装组件。
：
🔥 热词：#Canvas · #WebGPU · #UI · #35 · #个组件 · #in · #API · #实现的