DOMの何が悪いのですか？

DOMはひどいAPIであると言っている人々（特にCrockford）の声を聞き続けていますが、この声明を正当化するものではありません。ブラウザー間の不整合は別として、DOMがそれほど悪いと考えられる理由は何ですか？

Crockfordは「An Convenient API：The Theory of the Dom」というタイトルの広範なプレゼンテーションを行い、DOMについての意見を多少説明しています。長め（1時間18分）ですが、ほとんどのCrockfordのプレゼンテーションのように、非常に楽しく教育的です。

クロスブラウザーの不整合は彼の主な関心事のようであり、それがDOMに関して最も厄介なことの1つであることに同意します。彼は識別します：

• 独自のトラップ（ブラウザおよびサーバートラップ）、
• ルール違反、
• 企業戦争、
• 極端な時間的プレッシャー

さまざまな矛盾の背後にある重要な問題として、そのプレゼンテーション、セッション、または対話性を追加することは、Webの当初のビジョンでは予想されていませんでした。不整合の例には次のものがあります。

• document.all、Microsoftのみの機能、
• nameかつid互換性があったという事実。
• ノードの取得に関するさまざまな機能：
  
  • document.getElementById(id)、
  • document.getElementsByName(name)、
  • *node*.getElementsByTagName(tagName)）

さらに、DOMのトラバース、メモリリーク、イベントトリックルとバブリングを主にターゲットとするいくつかの例を続けます。「The DOM of DOM」というタイトルの要約スライドがあり、要約します。

• DOMバグリストには、ブラウザのすべてのバグが含まれています。
• DOMバグリストには、サポートされているすべてのブラウザーのすべてのバグが含まれています。
• 標準を完全に実装しているDOMはありません。
• DOMの多くはどの標準にも記載されていません。

要するに、それは乱雑で乱雑なAPIです。ちょっとしたピッキングのように思えるかもしれませんが、Web用に開発している場合、顧客が使用するブラウザを選択することはほとんどないことに留意する必要があります。主要なブラウザのそれぞれの少なくとも2つのバージョンですべてをテストする必要があるのは、すぐに古くなります。APIは一貫していると想定されており、DOMはブラウザ戦争の犠牲者でしたが、改善は進んでいます。W3C（および私たち全員）が望んでいるほどプラットフォームに中立ではありませんが、ブラウザベンダーは5年または10年前よりも協力したいと思っています。

DOMの何が問題になっていますか？Javaにヒントを得た構文（Crockfordが触れた）以外は何もありません。

「間違っている」とは、ブラウザベンダーに部分的に適用されます。開発者に当てはまる「間違った」もの; 「間違っている」とは無知に適用されます。

それで、どこから始めますか？

不思議な方向へ転がる…

ブラウザベンダー

まず、ブラウザベンダーは、数十年にわたって「最高」、「最速」、「最も簡単」などの競争を繰り広げてきました。最初の10年間（199x—2000）に、Microsoftはねぐらを支配しました。Internet Explorerは、次のような革新的なアイデアを導入しました。

• ブラウザのHTML解析エンジンを暴露するinnerHTMLと outerHTML、
• innerTextおよびを使用した簡単なテキスト操作outerText。
• *tachEventDOMレベル2イベントの設計図であるイベントモデル（*EventListener）。

それぞれが今日のWeb開発スタックに大きく貢献しています（良くも悪くも）。Operaは、バージョン7（2003）で3つすべてを実装することさえしました。

ただし、Netscapeには独自のDOMイベントモデル（*EventListener）がありました。2000年に、DOM Level 2 Events仕様になりました。Safari 1（2003）はこのモデルを実装しました。Opera 7（2003）もこのモデルを実装しました。Netscapeの遺跡がMozillaになると、Firefox 1（2004）がモデルを継承しました。

2000年から2004年までの20年間の最初のセクションでは、Microsoftが君臨しました。Internet Explorer 6（2001）は、当時最高のブラウザでした。競合他社の1つであるOpera 6（2001）はcreateElement、仕様が勧告（1998）になる前に、MicrosoftがInternet Explorer 4（1997）にDOM Level 1 Coreを実装していませんでした。

ただし、20年後の2番目のセクション（2004〜2010年）は、Microsoftにとって悲惨な結果になるでしょう。2003年、AppleはSafari 1.0をリリースしました。2004年、MozillaはFirefox 1.0を完成させました。マイクロソフトは、ブラウザの山の上にある王座で眠っているように見えました。Internet Explorer 7は2006年までリリースされませんでした。InternetExplorer 6のリリース日から5年のギャップがあります。Internet Explorerバージョン4〜6とは異なり、バージョン7はほとんど革新されていません。DOMの変更はわずかでした。ほぼ2年半後、Internet Explorer 8がリリースされました。マイクロソフトはその眠りから目覚め、他のブラウザーベンダーが多数のWeb標準の周りに形成した合体に気づきました。残念ながら、Microsoftの最後の真のイノベーションから時間がかかりすぎていました。ブラウザベンダー間で動きが生まれました。新しいDOM機能が仕様形式でW3Cに追加されました。マイクロソフトのアイデアは過去に残されました。Microsoftのイベントモデル（*tachEvent）DOM Level 2 Eventsモデルでは使用されませんでした。Internet Explorerは、バージョン9（2011）までDOMレベル3イベントモデルになる前のモデルを実装しませんでした。

Microsoft（DOM）の愚行は、次の点で要約できます。

• Windowsのコア機能としてのプレゼンス、および結果として生じるOSレベルのセキュリティ要件。

• クライアント側コードのActiveXへの依存。

• バージョン6（2001）以降、不思議なことに先細りになった革新。

（Web）開発者

第二に、開発者はある程度の責任を負います。Webが離陸し続けているため、Web開発で「だましている」人がますます増えています。これは、才能と労働倫理の希薄化につながりました。しかし、問題は主に態度にあります。「すばやく実行」が「正しく実行」よりも優先されます。その結果、無数のWebページはさまざまなブラウザーと互換性がありません。この非互換性の主な原因の1つは、「ユーザーエージェントスニッフィング」と呼ばれる方法です。この慣行は現在も使用されていますが、誤っており有害であることが証明されています。Operaは、バージョン10（2009）以降の「9.80」でユーザーエージェントバージョンを「フリーズ」することさえしました。これは、誤ったスクリプトが壊れないようにするためのものでした。「

無知

第三に、私の責任の非難は無知です。ブラウザベンダーが統一仕様を作成するのに十分なほど連携していないという事実に対する無知。マイクロソフトが他のブラウザーのユーザーを排除したという事実に対する無知。開発者が調査ブラウザ（特に流行していないブラウザ）を煩わせるには遅すぎるか近視であるという事実に対する無知。APIと実装には多くの違いがあります。ほとんどは、単純化されたまだ防御的なアプローチ（DOM 0に依存）と大量の研究とテストの両方で回避できます。無知は、Internet Explorer 6が地球上の荒廃であるという概念につながりました（前述のブラウザーの玉座のスポットを思い出してください）。

反射

悲しいことに、DOMは単なる誤解されたAPIです。多くの人が石を投げたい（FUD経由）が、その複雑さを学びたいという欲求はほとんどない。この無知の結果の1つは、DOM「セレクター」の導入です。中心的なDOMは、ドキュメントツリーを操作するためのAPIです。ツリートラバーサルは、解析されたドキュメントの形式が与えられた複雑な問題に使用する必要があります。DOM Selectors APIの導入により、開発者はブラウザーのCSSトラバーサルエンジンを活用できるようになりました。これは非常に便利ですが、ドキュメントツリーの本当の形を隠します。「セレクタ」を使用すると、要素ノードの取得が基本になります。ただし、DOMには他の11のノードタイプが指定されています。テキストノードは何ですか？ノードにコメントしますか？ドキュメントノード？これらは、DOMとの対話中にしばしば必要とされるノードでもあります。

結論

つまり、時間をかけてさまざまなDOM仕様を読んでください。できるだけ多くのブラウザでコードをテストします。Internet Explorerの動作がおかしいと思われる場合は、MSDNに問い合わせてください。ほとんどの場合、動作は文書化されています。

（歴史的な逸話は不正確である場合があり、不正確である可能性があります。不正確なものがあれば歓迎します。）

—マット

DOMはひどいAPIです

それは間違っています。DOMはひどいAPIではありません。

• まず、DOMは言語に依存しないことを忘れないでください。すべての主要言語でAPIが実装されています。これは、ブラウザで使用するのではなく、XMLを扱う必要があるすべての場所で使用するためです。

• 第二に、DOMはクラスではなくインターフェースを定義することに注意してください。これには非常に重要な意味があります。言語は、その構造と哲学に合った方法で実装できます。これにより、すべての言語の実装を他の言語と一貫させる必要がなくなります。

• 3番目に、DOMはXML（他のSAX）を解析する2つの主要な方法の1つであり、コンテキストに応じて、DOMは非常に効率的です。

あなたが言及しているのは、ブラウザDOMです。そして、DOMはブラウザーで「気分が悪い」ことに同意します。理由の一部は、ブラウザーの非互換性です。しかし、これらがブラウザーでのDOMの評判が悪い唯一の理由であることに同意しません。

• まず、考えてみると、DOMはこれらの非互換性が比較的克服しやすい分野の1つです。それに比べて、たとえば、イベントは非常に巧妙で、正規化するのが面倒です。

• 第二に、DOM機能の機能検出は他の領域よりも簡単です。

• 第三に、DOM 3の方がはるかに優れており、今日ではすべてのブラウザーがそのほとんどをサポートしています。

確かに、非互換性はいらいらしますが、それらに取り掛かると、DOMはそれほど刺激的ではなくなります。

また、私は、所有権のわな、企業の戦争などが理由であることに反対します。

• JavaScriptが軽量な言語であるという哲学と、Javaからインスピレーションを受けたDOMの実装との間の断絶が、フラストレーションの多くに貢献していると思います。

• 第二に、DOMはXML用に設計されており、HTML用に適合されています。したがって、ブラウザーには、HTML DOMとXML DOMの2つのDOMがあり、それらには互換性がありません。

• 第三に、ブラウザでのDOMトラバーサルは良くありません。HTML DOM用のXPathがないため、CSSセレクターエンジンが登場するまでは、トラバーサルを行うのは非常に面倒でした。

最後に、現代のブラウザでは（そして古いブラウザでは徐々に消えていく）今日、DOMを不良と呼ぶ必要はないと思います。確かに、ブラウザとAPIと実装の両方で改善されるでしょう。