Canvas UI登場：35種のWebGL/WebGPUコンポーネントでDOMを動的シェーダー化

• Canvas UIが35種のHTML-in-Canvasコンポーネントを公開し、ライブDOMへのWebGL/WebGPU適用を実現。
• Chromeの実験的APIを活用し、DOMの可読性やアクセシビリティを損なわずに高度なシェーダーエフェクトを実装。
• Chrome 148-150での動作が前提であり、商用利用は可能だが再販は制限されるMIT+Commons Clauseライセンス。

Web開発の現場において、DOM要素に派手なエフェクトをかけようとすると、往々にしてパフォーマンスの壁に突き当たる。CSSフィルターやSVGフィルターを重ねすぎてブラウザのメインスレッドが悲鳴を上げ、スクロールがカクつく――そんな経験は、フロントエンドエンジニアなら一度は通る道だろう。今回登場した「Canvas UI」は、この「DOMの重さ」という呪縛を、HTML-in-Canvasという実験的なAPIを介して、GPUのパワーで力技で解決しようとする野心的なライブラリだ。

Canvas UIは、単なるUIライブラリではない。React Bitsの作者であるDavid Haz氏が手掛けたこのプロジェクトは、35種類ものコンポーネントを揃え、ポインター駆動の流体エフェクトやVHSノイズ、ガラスレンズ効果などを、DOM要素そのものに対して適用する。特筆すべきは、これが「死んだビットマップ」を貼り付けているわけではないという点だ。Chromeのhtml-in-canvas APIを使い、ライブDOMをキャプチャしてテクスチャとしてアップロードし、シェーダーで歪ませる。これにより、テキストは選択可能であり、リンクはクリック可能、さらにはアクセシビリティツリーも維持されるという、エンジニアが最も懸念する「機能性と表現力のトレードオフ」を高度に両立させている。

しかし、シニアエンジニアの視点から見れば、この技術には「諸刃の剣」の側面があることも否定できない。現在、この機能はChrome 148から150までの実験的フラグ（canvas-draw-element）に依存しており、SafariやFirefoxでは動作しない。これは、クロスブラウザ対応が必須の業務アプリケーション開発においては、現時点では「実験室の中の玩具」に過ぎないことを意味する。だが、かつてのWebGLがそうであったように、ブラウザベンダーが標準化に向けて動き出せば、WebのUI表現は一気にリッチ化するだろう。我々が今すべきは、この技術を盲信することではなく、その「仕組み」を理解し、将来的なUIのパラダイムシフトに備えておくことだ。

Canvas UIの導入を検討する際、まず直面するのが「shadcn-compatible」なレジストリ形式という配布形態だ。これはnpmパッケージとしてインストールするのではなく、npx shadcn@latest add @canvas-ui/liquid-reactのように、ソースコードを直接リポジトリに取り込む方式を採っている。これは、ライブラリのアップデートが「再インストールと差分調整」を意味することを意味し、大規模なプロジェクトでは依存関係の管理がスパゲッティ化するリスクを孕んでいる。しかし、この方式により、開発者はコンポーネントの内部ロジックを完全に制御下に置くことができ、必要に応じてシェーダーコードをカスタマイズすることも可能だ。

技術的な実装詳細を見ると、このライブラリの「泥臭いエンジニアリング」が光る。例えば、LiquidコンポーネントはIntersectionObserverを用いて、要素が画面外に出た瞬間にループを停止させる。また、prefers-reduced-motionを尊重し、アンマウント時にはテクスチャやリスナーを適切に解放する。こうした細やかなメモリ管理は、GPUリソースを浪費しがちなWeb開発において、非常に重要なプラクティスだ。Flavio Copes氏が指摘するように、このライブラリをダッシュボードや決済フローのような「信頼性が最優先される場所」に使うのは避けるべきだが、ポートフォリオサイトやキャンペーンページでのインパクトは絶大だろう。

以下に、Canvas UIが提供する主要な技術スタックと制約を整理する。

このライブラリが提示する「ライブDOMのシェーダー化」というアプローチは、Webの未来を占う試金石だ。Googleが主導するこの技術が、果たして「Embrace, Extend, Extinguish」の再来なのか、それともWebの表現力を底上げする標準への第一歩なのか。我々エンジニアは、この技術の背後にある標準化プロセス（WHATWGでの議論など）を注視しつつ、自らのプロダクトに「本当に必要な表現」とは何かを問い直す必要がある。単に流行りのライブラリを導入するのではなく、その技術がブラウザの標準仕様として定着するまでの「移行コスト」を計算できるかどうかが、シニアエンジニアとしての腕の見せ所ではないだろうか。