DOMの何が悪いのですか？
私は人々（特にクロックフォード）がDOMはひどいAPIだと言っていますが、この声明を正当化するものではありません。ブラウザ間の不整合は別として、DOMが非常に悪いと考えられるいくつかの理由は何ですか？
Crockfordは "An Convenvenient API：The Theory of the Dom" というタイトルの広範なプレゼンテーションを行っており、DOMに関する彼の意見を多かれ少なかれ説明しています。長い（1時間18分）ですが、ほとんどのクロックフォードのプレゼンテーションと同様に、非常に楽しく教育的です。
クロスブラウザーの不整合が彼の主な関心事であるようであり、それがDOMの最も厄介なことの1つであることに同意します。彼は特定します：
- 独自のトラップ（ブラウザおよびサーバートラップ）、
- ルール違反、
- 企業戦争、
- 極端な時間のプレッシャー
さまざまな不整合の背後にある主要な問題として、そのプレゼンテーション、セッション、または対話性を追加することは、Webの元のビジョンでは予想されていませんでした。不整合の例には次のものがあります。
- _
document.all_、Microsoftのみの機能、 nameとidは互換性があったものです。- ノードの取得に関するさまざまな機能：
document.getElementById(id)、document.getElementsByName(name)、*node*.getElementsByTagName(tagName)）
さらに、いくつかの例を続けます。主に、DOMのトラバース、メモリリーク、イベントの細流化とバブリングをターゲットとしています。 「DOMの亀裂」というタイトルの要約スライドがあります。
- DOMバグリストには、ブラウザのすべてのバグが含まれています。
- DOMバグリストには、サポートされているすべてのブラウザーのすべてのバグが含まれています。
- 標準を完全に実装しているDOMはありません。
- DOMの多くはどの規格にも記述されていません。
つまり、乱雑で乱雑なAPIです。ひどいことに思えるかもしれませんが、Web用に開発しているときに、顧客が使用するブラウザーを選択することはめったにないことを覚えておく必要があります。主要な各ブラウザの少なくとも2つのバージョンですべてをテストする必要があることは、すぐに古くなります。 APIは一貫しているはずであり、DOMは browser wars の犠牲になりましたが、改善されています。それはW3C（そして私たち全員が思う）が望む プラットフォームニュートラル ほどではありませんが、ブラウザーベンダーは5年または10年前よりも協力を熱望しているようです。
DOMの何が問題になっていますか？ Javaにヒントを得た構文（Crockfordが触れた）以外は何もありません。
「間違っている」ということは、ブラウザのベンダーに部分的に当てはまります。 「間違っている」ものは開発者に適用されます。 「間違っている」とは無知に適用されます。
では、どこから始めればよいのでしょうか。
不思議な方向へ転がる…
ブラウザベンダー
まず、ブラウザベンダは何十年にもわたって「最高」、「最速」、「最も簡単」などになるために競争してきました。最初の10年間（199x〜2000年）に、マイクロソフトはねぐらを支配しました。 Internet Explorerは、次のような革新的なアイデアを導入しました。
- ブラウザのHTML解析エンジンを
innerHTMLおよびouterHTMLとして公開します。 innerTextおよびouterTextを使用した簡単なテキスト操作- イベントモデル（
*tachEvent）DOMレベル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）がモデルを継承しました。
20年間の最初のセクション（2000〜2004年）では、Microsoftが最高を支配しました。 Internet Explorer 6（2001）は、当時としては最高のブラウザでした。競合他社の1つであるOpera 6（2001））は、DOMレベル1コア（createElementなど）をまだ実装していませんでした。Microsoftは、これをInternet Explorer 4（1997）に実装しました仕様が勧告になる前（1998）。
ただし、20年目の2番目のセクション（2004〜2010年）は、Microsoftにとって悲惨な結果となるでしょう。 2003年にAppleがSafari 1.0をリリースしました; 2004年にMozillaがFirefox 1.0を完成させました。Microsoftはブラウザ山の頂上で王座に眠っていたようです。InternetExplorer 7は2006年までリリースされませんでした：5ギャップInternet Explorer 6のリリース日からさかのぼります。InternetExplorerバージョン4から6とは異なり、バージョン7はほとんど革新がなく、DOMの変更はわずかでした。ほぼ2年半後、Internet Explorer 8がリリースされました。Microsoftは他のブラウザーベンダーが多数のWeb標準の周りに形成された合体に気づきました。残念ながら、Microsoftの最後の革新から長い時間が経過しました。ブラウザーベンダー間で動きが生まれました。新しいDOM機能が仕様形式でW3Cに追加されました; Microsoftのアイデアは過去に残されました。Microsoftのイベントモデル（*tachEvent）は、DOMレベル2イベントモデルでは避けられました。 Internet Explorerは、DOMレベル3イベントモデルとなったバージョン9（2011）まで上記のモデルを実装しませんでした。
Microsoft（DOM）の愚かさは、次の点で要約できます。
windowsのコア機能としての存在、およびその結果としてのOSレベルのセキュリティ要件。
クライアント側コードのActiveXへの依存。
バージョン6（2001）以降、奇妙に先細りになったイノベーション。
（Web）開発者
次に、開発者はある程度の責任を負います。 Webの普及が進むにつれ、Web開発に「手を出す」人がますます増えています。これは、才能と労働倫理の希薄化につながりました。しかし、問題は主に態度にあります。 「すぐに終わらせる」は「正しく終わらせる」よりも優先されます。その結果、無数のWebページはさまざまなブラウザと互換性がありません。この非互換性の主な原因の1つは、「ユーザーエージェントのスニッフィング」と呼ばれる手法です。この慣行は現在も使用されていますが、誤りと有害の両方であることが証明されています。 Operaは、バージョン10（2009）以降では、ユーザーエージェントのバージョンを「9.80」に「フリーズ」することさえありました。これは、誤ったスクリプトが壊れないようにすることを目的としていました。 「機能テスト」と呼ばれる（現時点ではナイーブな形式ですが）が開発者に採用されています。
無知
第三に、私の非難の好ましい点は無知です。ブラウザーベンダーが連携して仕様を統一するのに十分なほど協力していないという事実に対する無知。マイクロソフトが他のブラウザーのユーザーを避けたという事実に対する無知。開発者があまりにも怠惰または近視的であり、ブラウザを研究することに煩わしいという事実（特にen vogueでないもの）に対する無知APIと実装。多くの場合、大量の研究とテストの両方に加えて、単純化された防御的なアプローチ（DOM 0への依存）で回避できます。無知は、Internet Explorer 6が地球に危害を加えるという考えにつながっています（前述のブラウザーの王座のスポットを思い出してください）。
反射
悲しいことに、DOMは誤解されているAPIです。多くの人が（FUDを介して）石を投げたいと思っていますが、その複雑さを学びたいと思う人はほとんどいません。この無知の結果の1つは、DOM「セレクター」の導入です。 DOMは、ドキュメントツリーを操作するためのAPIです。解析されたドキュメントの形式を考えると、ツリートラバーサルは複雑な問題に使用する必要があります。 DOMセレクターAPIの導入により、開発者はブラウザーのCSSトラバーサルエンジンを活用できるようになりました。これは非常に便利ですが、ドキュメントツリーの本来の形式を隠します。 「セレクター」を使用すると、要素ノードの検索は初歩的です。ただし、DOMには他に11のノードタイプが指定されています。テキストノードとは？コメントノード？ドキュメントノード？これらは、DOMとの対話中に必要になることが多いノードでもあります。
結論
つまり、時間をかけてさまざまなDOM仕様を読んでください。できるだけ多くのブラウザでコードをテストします。 Internet Explorerが異常な動作をしていると思われる場合は、MSDNを参照してください。ほとんどの場合、動作は文書化されています。
（歴史的な逸話は不正確である可能性があり、不正確である可能性があります。不正確な点があれば、ぜひお知らせください。）
—マット
DOMはひどいAPIです
[〜＃〜] wrong [〜＃〜]です。 DOMはひどいAPIではありません。
まず、DOMは言語に依存しないことを覚えておいてください。すべての主要言語がAPIを実装しています。これは、ブラウザでは使用しないためですが、XMLを処理する必要があるすべての場所で使用します。
第二に、DOMはクラスではなくインターフェースを定義することに注意してください。これは非常に重要な意味を持っています。言語は、その構成と哲学に適した方法で実装できます。これにより、すべての言語が他の言語との実装において一貫している必要がなくなります。
第3に、DOMはXMLを解析する2つの主要な方法の1つであり（他はSAXです）、コンテキストによっては、DOMは非常に効率的です。
あなたが参照しているのはブラウザのDOMです。また、DOMはブラウザで「気分が悪い」ことに同意します。理由の一部は、ブラウザの非互換性です。しかし、それらがブラウザでのDOMの評判が悪い唯一の理由であるとは私は同意しません。
まず、考えてみれば、DOMは、これらの非互換性が比較的克服しやすい分野の1つです。それに比べて、たとえば、イベントは正規化するのが非常に難しく、煩わしいものです。
第2に、DOM機能の機能検出は他の領域よりも簡単です。
第3に、DOM 3の方がはるかに優れています。現在、すべてのブラウザがそのほとんどをサポートしています。
確かに、非互換性は厄介ですが、非互換性に取り掛かると、DOMはそれほど刺激的ではありません。
私はまた、独自の罠、企業戦争などの理由がその理由であることに同意しません。
JavaScriptが軽量言語であるという哲学と、DOMの実装がJava-にインスパイアされたものである）との間の分離点であると私は思います。
次に、DOMはXML用に設計されており、HTML用に適合されています。したがって、ブラウザには、HTML DOMとXML DOMの2つのDOMがあり、互換性がありません。
3番目に、ブラウザーでのDOMトラバーサルは適切ではありません。 HTML DOMのXPathがないので、CSSセレクターエンジンの前に、走査を行うのは本当に面倒でした。
最後に、私はtodayが最新のブラウザで（そして古いブラウザが徐々に消えていく中で）DOMを悪いと呼ぶ必要がある理由はないと思います。それは確かにブラウザでより良くなるでしょう-APIと実装の両方。