HTML in Canvas

当前判断

• HTML in Canvas 和 WebGPU 是相关方向，但不是同一层概念
• 更准确地说，HTML in Canvas 是一种 UI 渲染范式，而 WebGPU 是一种 底层图形能力
• 这条线很值得和 WebGPU、3D 编辑器、AI 原生编辑器 放在一起看
• 它的核心意义不是“把 HTML 画进 Canvas”这么简单，而是 脱离传统 DOM，自己接管布局、渲染和交互

我目前的理解

• 浏览器传统 UI 主要依赖 DOM + CSS + 浏览器布局引擎
• HTML in Canvas 这条线，本质上是在尝试：
  • 不直接依赖 DOM 做复杂界面
  • 在 canvas 中统一绘制 UI
  • 自己处理布局、事件命中、滚动、缩放、文本和层级
• 所以它更接近：
  • 设计工具
  • 白板工具
  • 代码编辑器 / 可视化编辑器
  • 空间编辑器
  • 游戏化 UI

为什么值得关注

• 当交互复杂度非常高时，传统 DOM 往往会变得越来越重
• 在画布体系里，坐标、缩放、命中检测、选择框、多选、拖拽、图层会更统一
• 如果产品天然就是“画布应用”，这条路往往比 DOM 更顺
• 如果后面叠加 AI agent，语义节点、场景树、统一渲染树也会更重要

和 WebGPU 的关系

• WebGPU：底层图形 API
• wgpu：Rust 生态里的图形抽象层
• HTML in Canvas：UI 层/渲染范式
• 3D 建筑编辑器：上层应用形态

可以粗略理解为：

WebGPU / wgpu
-> 提供底层图形能力

Canvas UI / HTML in Canvas
-> 决定 UI 是否脱离 DOM

3D 编辑器 / AI 原生编辑器 / 空间工具
-> 具体产品形态

这条线真正该看什么

• 是否真的解决了复杂交互问题，而不只是做了一个炫技 demo
• 是否有自己的布局系统、事件系统、文本系统
• 是否能承载真实产品，而不是只能展示几个组件
• 是否对 AI / agent 更友好，比如：
  • 场景树明确
  • 语义节点明确
  • 操作可编排
  • 状态和渲染树可机器理解

和传统前端的差异

• 传统前端更偏页面和表单
• HTML in Canvas 更偏工具和编辑器
• 它不一定要替代普通网页，但很可能会吃掉一部分高交互产品形态

我现在的结论

• 这不是一个小技巧，而是一条 产品形态和前端架构 变化线索
• 它和 WebGPU 有强关联，但不应该混为一个词
• 如果你后面继续观察，比较好的组合是：
  • WebGPU 看底层能力
  • HTML in Canvas 看 UI 范式
  • 3D 编辑器 / 建筑编辑器 / AI 原生工具 看实际落地

后续观察角度

• 哪些项目已经不用 DOM 承载核心交互
• 哪些团队在做 canvas-native editor
• 哪些项目同时出现了：
  • semantic scene graph
  • agent-friendly
  • editor
  • canvas-native UI
  • WebGPU