为何 Google Docs 选择 Canvas 而非 HTML
You might want to build your WebApp in Canvas instead of HTML
我一直在好奇 Google、Microsoft 等巨头如何构建能在各种设备上流畅运行的 WebApp。答案往往出人意料：他们大量使用 Canvas 元素，而非传统的 HTML DOM。从 Google Docs 到 Miro，再到我们自己的 Hivekit 调度器，Canvas 在处理复杂渲染、无限画布和缩放交互时展现了独特优势。虽然它牺牲了浏览器自带的无障碍和文本选择功能，但在需要极致性能和控制力的场景下，Canvas 能提供更一致、更快速的体验。本文分享了我们在构建高性能 WebApp 时选择 Canvas 的考量、遇到的挑战以及最佳实践。
不要仅仅因为 Canvas 听起来更快就选择它，只有当你的界面不再像文档，而开始更像场景时，才是使用它的正确时机。
- dinkelberg
当你在 Canvas 上绘制所有内容时，浏览器的开发者工具会变得几乎毫无用处。如果大家都开始使用在 Canvas 上绘制的框架，那将会是一件令人难过的事。这恐怕比 WebAssembly 出现时更让人难过。不过，人们或许可以为这些框架编写新的开发者工具。
我也想象到，这将对 Web 无障碍性造成重大打击。
- frollogaston
从事浏览器开发的人曾抱怨说，HTML/CSS 并不是进入引擎的自然接口，因此效率低下且存在各种棘手的边缘情况。我对浏览器引擎一无所知，但作为用户，当我不是在做纯文本网站时，总觉得 CSS 用起来很别扭，所以在我的副项目中一直重度依赖 React。
我一直在考虑做一个玩具项目，尝试在 Canvas 之上构建我自己的 HTML/CSS 替代方案，灵感来源于 Wayland 实际上比 X11 的抽象层级更低。
- zarzavat
Canvas 是最后的救命稻草，只有当你绝对无法用其他方式构建时才会使用。
当你使用 Canvas 时，你放弃的不仅是无障碍性，还有浏览器在使用原生渲染树时为你透明执行的优化。没有任何保证说你的应用在 Canvas 上会更快，它完全可能更慢。你真的认为你能用一种连原生整数类型都没有的语言写出的代码，去击败浏览器的 C++ 代码吗？或许你可以，但你最初的假设应该是你做不到。