CanvasでWebアプリを構築すべき理由：Google DocsやMiroが選ぶ理由
You might want to build your WebApp in Canvas instead of HTML
Google DocsやMiroなど、大手企業のパフォーマンス重視のWebアプリがCanvasを採用している理由を解説。DOM要素と比較したCanvasの利点（速度、制御、一貫性、移植性）と欠点（アクセシビリティ、入力処理など）を整理し、Canvasが適するユースケース（大規模な空間ワークスペース、ズーム・パン操作、複雑なレンダリング順序）を提示。さらに、レンダリング管理、複数Canvasのレイヤー化、デバイスピクセル比への対応、イベント処理など、実装上の重要なポイントをコード例とともに紹介する。
CanvasはHTMLの高速な代替品ではありません。より低レベルのレンダリングツールであり、より多くの制御を提供する一方で、ブラウザの仕事の多くを自分で引き受けることになります。
HNでの議論
57- josephg
やめておけ。
ネイティブコントロールには、何十から何百もの微妙なUI操作がある。テキスト入力要素を考えてみよう。macOSにはテキストショートカットがある。Cmd+Aで全選択、Cmd+←/→で単語単位の移動、Page Up/Page Down、Home/End、スペルチェック。右クリックメニューにはOSのテキストサービスを含む約10のオプションがある。iOSやAndroidでテキスト入力要素をタップすると、システム設定で構成されたネイティブのオンスクリーンキーボードが表示される。主要なOSバージョンごとに、UIは微妙に変化する。
この機能をWebブラウザで再実装することは不可能だ。ブラウザAPIでは、必要なキーボードショートカットの多くをインターセプトできない。macOSのテキストサービスやネイティブのiOSキーボードUIにアクセスすることもできない。
これをブラウザで再実装しようとする人もいるが、いつも使い心地が最悪だ。ほぼネイティブだが、ラグがある。何もかもが少しずつおかしい。ページ上のテキストを正しく選択できない。フォントのレンダリングが微妙に間違っている。機能しないキーボードショートカットに対する筋肉記憶がある。それが嫌いだ。
- dinkelberg
Canvasにすべてを描画すると、ブラウザの開発者ツールがほとんど役に立たなくなる。誰もがCanvasに描画するフレームワークを使い始めたら悲しいことになるだろう。WebAssemblyが登場した時よりも悲しいかもしれない。おそらく、それらのフレームワーク用の新しい開発者ツールを書くことはできるだろう。
また、これはWebアクセシビリティにとって大きな後退になるだろう。
- groomlake
GoogleやMicrosoftなどがどのようにWebアプリを構築しているのか、いつも気になる。どんなコンピュータでも、最高級の高速マシンから、配線がむき出しのジャンクPCまで、うまく動作する必要があるからだ。
私の経験では、MicrosoftのWebアプリ（現在はデスクトップアプリの多くを含む）はかなりもっさりしている。Copilot ChatのWebサイトでさえも。チャットボックスとセッションのトランスクリプトを、もっさりさせないことなんて、どれほど難しいのだろうか？
- efficax
アクセシビリティについては、もちろん一言も触れられていない。視覚障害者にとっては、Canvasも同様に盲目だ。多くの作業なしにはアクセスできない。DOMをアクセシブルにする方がはるかに簡単だ。
- lisperforlife
私はこれをブルーボックス問題と呼んでいる。SAPで働いていた頃、ブルーボックスコントロールというものがあって、C++/MFCアプリにブラウザ（shdocvw）を埋め込んでいた。ほとんどすべての厄介なUIバグは、そのコントロールから発生していた。今は逆の方向で同じことが起きている。5年ごとに、ブラウザを配布エンジンとして使い、ボックスによってレンダリングされるUIサーフェスを提供するという素晴らしいアイデアを思いつく。これは歴史的に一度も成功したことがない。アプレット、ActiveXコントロール、Flash、Flex（これもFlash）、Silverlight、Flutter...そして今これだ。問題は、開発者ツール、スクリーンリーダー、ブラウザ拡張機能、そして考慮するのが難しい他のすべての小さなことだ。