基本原則から考えるDOMの再考

2025年8月6日原文(acko.net)

概要

DOM とその周辺APIは時代遅れで肥大化
Webアプリ開発 ではDOMの直接操作を避ける傾向
CSS は直感的でないレイアウトモデルと複雑な継承
SVG の統合は便利だが一貫性に欠ける
新しい UIツールキット への転換が必要

DOMを原点から再考する

WebAssembly の普及でサーバー側は進化したが、クライアント側の DOM は10年前と大差ない現状
WASM からDOMアクセスが「解決済み」とされるが、そもそもDOMを使いたい理由自体が問われていない
DOMや関連APIを「引退」させるべき時期と主張
Chrome のdocument.bodyには350以上のプロパティやメソッドが存在、さらにCSSプロパティは660にも及ぶ現状
プロパティとメソッドの区別が曖昧で、getterがレイアウト計算を引き起こすことも
古いイベントプロパティなど、レガシーな機能が多数残存
DOMは肥大化し続け、Webページ制作者とWebアプリ開発者で問題意識に差
多くの開発者はDOMの直接操作を避け、JSフレームワークを利用
DOMの宣言的な機能（innerHTMLなど）は現代UIパターンに適合しない
同じことを実現する方法が多すぎ、どれも洗練されていない

Web ComponentsとDOMの限界

Web Components はネイティブなコンポーネントモデルだが、普及せずAPIも扱いづらい
Shadow DOMは新たな入れ子・スコープ問題を導入
DOMの本質的な問題はSGML/XML由来の「文字列型」中心設計
React系フレームワークはこの問題を回避
状態管理をDOMに持たせるのは不適切と認識
HTML自体は10年以上本質的な進化がなく、ARIAのみが目立つ変化
セマンティックHTMLの理想は未達成で、明確な設計指針が不在
HTMLの管理はWHATWG（ブラウザベンダー主体）に移行し、ビジョン不在のまま小手先の改良が続く
CSSもテンプレート言語的な方向に拡張され、複雑化
contentEditableの実用化は困難、Google DocsやNotion開発者も苦戦
プログレッシブエンハンスメントやマークアップとスタイルの分離という旧来の価値観は失われつつある
現代のWebアプリはHTML/CSS/SVGを無理やりUIツールキット化しているが、巨大なオーバーヘッドと非効率

CSSの本質的な問題

CSS のレイアウトモデルは直感に反し、制約解決型と誤解されがち
- 例: 親要素の高さが未定義の場合、子要素のheight: 50%は無効
CSSのレイアウトは「外から内（outside-in）」と「内から外（inside-out）」の2パス制約伝播
- outside-in：アプリケーションフレーム等、親がサイズを決定
- inside-out：テキストや段落など、子が親を伸ばす
CSSはデフォルトでinside-out、outside-inは明示的に指定が必要
flex box（display: flex）は自動レイアウトに便利だが、内部的には2回レイアウト計算が必要で複雑
- contain: sizeやflex-basisで再帰的依存を回避可能
containやwill-changeなどの新機能はレイアウト最適化に寄与するが、DOM全体の制約伝播を部分的に断ち切る
CSSは本質的に「文書指向」であり、アプリケーションUIには不向きな設計

CSS・SVGの「良い部分」と設計上の問題

flex boxは理解すれば直感的で強力、グリッドレイアウトも同様だが記法が複雑
本来なら「外から内」「内から外」を明示的なコンテナ・配置モデルで分けるべき
CSSは「リッチテキスト用の継承型スタイル」と「ブロック・インライン要素のレイアウトシステム」が混在
- font-sizeなどは継承するが、borderなど大半のプロパティは継承しない
emスケーリングは論理ピクセル・デバイスピクセルの概念に置き換えられ、現代では重要性が低下
SVGはDOM統合で動的描画やアイコンスタイル調整に有用
- ただしCSSと完全な互換性はなく、座標の文字列化など独自仕様あり
- CSSもSVG的な機能（角丸、グラデーション、マスク等）を取り入れるが不十分
- SVGはポリゴンヒットテスト等、CSSでは不可能な機能あり

レイアウト・API設計の課題

HTML/CSS/SVGの使い分けは特有のトレードオフが多く、一貫したUI構築が困難
例示される問題点：
- text-ellipsisは段落全体の省略不可、テキスト計測APIも不十分
- position: stickyは本来簡単なはずが、実際は複雑な入れ子構造が必要
- z-indexは絶対値指定で、相対的なZ階層管理ができず「z-index戦争」が発生
いずれもv1仕様のまま本質的なプリミティブ提供に至っていない

まとめ：新しいUIツールキットへの転換

DOMは時代遅れ、CSSは部分的に有用だが設計上の限界
SVGは必要悪的存在
全体として、現行のWeb UI基盤は抜本的な再設計が必要
新しいUIツールキット・API設計への転換が求められる

Hackerたちの意見

うーん、この記事はDOMについての正しい事実を述べてるけど、結論はめちゃくちゃ間違ってるね。ほとんどの開発者は、ずっとDOMを扱うのが怖いと思ってる。こういう非合理的な感情は新しいものじゃない。理由は全然わからないけど、ツリーモデルが大学で学んだ開発者たちをめちゃくちゃ怖がらせてるのが不思議。コンピュータサイエンスの教育ではデータ構造やツリーモデルにたくさんのエネルギーを使ってるのにね。それに、WASMについての会話もさらに奇妙になる。ほとんどの大学卒の開発者はDOMを恐れてる。そう、感情としての恐怖で、完全に非合理的。これについては、15年以上フルタイムのJS開発者として見てきたから信じてほしい。開発者たちは、無駄な抽象化でDOMから逃れようとしてるけど、なぜそうするのか自分でもわからないことが多い。彼らはその非合理的なことを隠すために多くのエネルギーを注いでるんだ。他の開発者は、この感情の悪夢を受け入れずに、WASMがJSを置き換えてくれればいいのにと思ってる。これが問題なのは、WASMをデプロイするのにJSやDOMと関わる必要がないけど、WASMは含まれているウェブページを無視するサンドボックスだから、全くの置き換えにはならないってこと。WASMが置き換えになるためには、含まれているページへの完全なDOMアクセスを得る必要がある。ブラウザメーカーは明確なセキュリティ上の理由からそれを拒否してる。だから、開発者たちは無駄な抽象化でDOMから逃れようとし、他の開発者はまだ恐れていることに気づかずにそのものを受け入れようとしてる。これって本当に変だけど、ソフトウェアがどうなってるのか不思議に思う非開発者にとっては面白い話になるね。

└

ブラウザメーカーは明確なセキュリティ上の理由からそれを拒否してる。だって、あくまでJavaScriptだけがそんなにひどくやらかすべきなんだから。

└

DOMを直接扱うのが難しい理由は、ある状態から別の状態に移行するために任意のパッチを実装しなきゃいけないから。Reactのようなフレームワークの全てのポイントは、その問題を避けるために自動的にパッチを作成して適用してくれることなんだ。これは非合理的じゃないよ。むしろその逆だね。

└

3年前にウェブ開発のビジネスを閉じたんだ。ウェブに関わる多くの人が、どうやって全てが機能するのか理解するための努力をしたくないと感じてるのに気づいた。彼らは「それ」をやるためのライブラリがどこかにあるはずだと思ってるけど、実際には標準のコンポーネントや機能を使えば簡単にできることなんだ。もう一つの問題は、過去のことに基づいて恐れを抱いている人たちがいること。確かに、ウェブで派手なことをするのはもっと難しかったけど、彼らは往々にして、昔はできなかったことをウェブにやらせようとしてる。今は基本的な組み込み機能を使えばできるし、その方が簡単なことが多いよ。

└

WASMがDOMアクセスを持たない理由は、多くの最近のDOM APIがJavaScriptオブジェクトやクラス（イテレータなど）を返したり期待したりするから。だから、DOMとWASMの間には薄いJSのグルーラッパーが必要になる。セキュリティは関係ないよ。パフォーマンスを除けば、WASM+最小限のJSグルーで、JSができることはすでに何でもできるから。

└

WASMが置き換えられるためには、含まれているページへの完全なDOMアクセスを得る必要がある。完全な置き換え、つまり全くJavaScriptが必要ない状態になるには、WASMがDOMにアクセスできる必要がある。でも、JavaScriptの代わりに書く言語として置き換えるためには、DOMバインディングを簡単に生成できるから、JavaScriptを介してトランポリンすることができる。これをWASMが登場して以来、みんなやってることだよ。WASMに直接DOMアクセスを与えることは新しいことを可能にするわけじゃなくて、単にJSバインディングをスリム化して、時間やメモリのパフォーマンスを改善する可能性があるだけ。> ブラウザメーカーは明確なセキュリティ上の理由からそれを拒否してきた。実際、彼らはそれを実現するためにかなりの道のりを進んでいる。正しく行うために時間をかけているだけで、これまでに少なくとも3つの異なる方向に進んできた。でも、最初からそれが最終的な目標であることは明らかだった。

└

なぜかわからないけど、ツリーモデルは大学教育を受けた開発者を怖がらせる。ツリーモデルを「怖がる」人はほとんどいないよ。DOMを扱う問題は、以下のようなことがあるから。 - 90年代のJAVAのように冗長で扱いにくいAPIで、最も簡単なことをするのに大量のボイラープレートが必要 - 自分のことを簡単にできるほど低レベルでもなく、既存のビルディングブロックから必要なものを作るには高レベルすぎる非常に貧弱なAPI - 完全に非合成的なAPI - 何かをするのを妨げるレンダリングシステムで、要素のボーダーを変更するだけでページ全体の再レイアウトを引き起こす可能性がある数百の落とし穴やコーナーケースに気を配らなければならない - 静的なウェブページ以上の複雑なものには非常にパフォーマンスが悪いレンダリングシステム（それすらもかろうじてこなしている）。人々が示す「驚くべきパフォーマンスの偉業」は、非常に注意深くコーディングされたものか、他のツールキット（例えば、canvasやwebgl）と同じ技術を使っているか、他の何かにとっては絶対的な基本条件だよ。先週のフロントページの記事では、3つの長方形をアニメーションさせるのに60%のCPUと25%のGPUが必要だったって書いてあった。https://www.granola.ai/blog/dont-animate-height > だから、DOMから逃げるために無駄な抽象化を使ってキャリアを投資する人が出てくる。過去15年ほどの抽象化は、DOMが非常にパフォーマンスが悪く、母親ですら愛さないようなAPIだから、DOMから逃げようとしてきたんだ。

よくみんながDOM、HTML、CSSがどんどん複雑になってるって嘆いてるよね。垂直センタリングや仮想化のような簡単なタスクでさえ難しいし、600以上のCSSプロパティ、たくさんのJavaScriptメソッド、漏れ出る抽象化、{ contain: size }。多くの問題には同意するけど、現実的にどうやって複雑じゃなくなるのか想像するのも難しい。もしそれが一つの非常に良く考えられたビジョンの結果で、開発者たちが最新のAPIに従うことを期待されていたら（AppleのiOSランタイムみたいな）、タグの使い方が一つに決まって、無駄がすぐに削ぎ落とされて、機能が非推奨から消えるのも早いかもしれない。でも、実際には多くの委員会によって設計された製品で、数十年にわたって後方互換性を維持してきたし、基本的にはハイパーリンクされたドキュメントレイアウトエンジンから成長した無料のランタイムで、今ではネイティブアプリに匹敵する完全にダイナミックなアプリケーションを動かしてる。それでも新しい開発者にとってはかなりの敷居が低いから、驚くほど頑丈なんだ。確かに、簡単そうな機能に対して大量のマークアップが必要なアプリもあるけど（Slackの入力ボックスの例とか）。でも、代わりにブラウザベンダーがすべてを組み込んでしまったら、すべてのアプリが彼らが正しいと思う方法に縛られてしまう。ある程度の混沌は健康的かもしれないね。

└

現実的にどうやって複雑じゃなくなるのか想像するのも難しい。簡単だよ。2つの標準が必要だった。1つは「アプリケーションのためのウェブ」で、VM、標準ライブラリ、バイトコード、RPC、UIフレームワーク、コントロールの標準ライブラリに基づいて構築されているもの。そしてもう1つは「ウェブページのためのウェブ」で、これはHTML5以前の時代には解決済みの問題だった。JavaやFlash（セキュリティの観点からは非常に問題があるけど）は、「アプリケーションのためのウェブ」を構築するための基盤としてHTML5+/CSS3+/JS/WASMよりも良かったかもしれないけど、GoogleやMicrosoft、MozillaがOracleやAdobeにその鍵を渡すのは耐えられなかったんだ。すべてが政治的なもので、結果的にすべてが悪化して、より複雑で非効率的になってしまった。

└

ウェブは複雑なアプリケーションに合わせて成長してきたけど、プラットフォーム自体も無駄に膨れ上がってるよね。新しい機能（例えば、Canvas提案のHTMLみたいな）を、すでにバラバラなパズルに無理やり押し込まなきゃいけないから。後方互換性は、技術的な成果というより理想的な名誉のバッジになっちゃった。この記事は、ウェブの有機的な成長にもかかわらず、実際にはそれほど頑丈じゃない技術的な部分に触れていて、いい仕事してると思う。盆栽も時々剪定が必要だしね。正しい方法が一つだけってことはないけど、Flashの時代からインターフェースの設計方法はかなり収束してきたから、少なくとも「大体合意された方法」で会話を進められるようになった。

└

確かに、いくつかのアプリケーションは、シンプルな機能に対して大量のマークアップを持つ傾向がある（Slackの入力ボックスの例みたいに）。でも、代わりにブラウザベンダーが全てを組み込んじゃうと、すべてのアプリが彼らが正しいと思う意見に縛られちゃう。ある程度の混沌は健康的かもしれない。あるいは、すぐに使える機能を提供するコントロールのセットを用意して、便利なAPIを提供して、みんながそのコントロールを拡張したり、自分のものを作ったりできるようにすればいい。ウェブプラットフォームはどちらも提供してない。これを、太陽の下にある他のすべてのUIツールキットと比べてみて。90年代のTurbo Visionは、ウェブが提供するものよりもずっと優れたツールキットだったよ。

└

垂直センタリングについては、20年前にこれを試したときは本当に面倒だった。レイアウト全般が過去20年で大幅に簡素化されたことを考えると、当時はすべてがテーブルに詰め込まれていたことを思い出すよ。だから、「DOM、HTML、CSSがどんどん難しくなっている」と言われても、そのアマチュアで根拠のない意見は無視していいと思う…ハハ！

Hacker Newsで議論の続きを見る

ハクソク