Was ist so schlimm am DOM?

Ich höre immer wieder Leute (insbesondere Crockford), die sagen, dass das DOM eine schreckliche API ist, aber diese Aussage nicht wirklich rechtfertigen. Abgesehen von browserübergreifenden Inkonsistenzen, was sind einige Gründe, warum das DOM als so schlecht eingestuft wird?

Crockford hat einen ausführlichen Vortrag mit dem Titel "Eine unbequeme API: Die Theorie des Dom" gehalten, in dem er mehr oder weniger seine Meinung zum DOM erklärt. Es ist langwierig (1h 18m), aber wie die meisten Crockford-Präsentationen ist es sehr unterhaltsam und lehrreich.

Browserübergreifende Inkonsistenzen scheinen sein Hauptanliegen zu sein, und ich stimme zu, dass dies die nervigste Sache am DOM ist. Er identifiziert:

• Proprietäre Traps (Browser- und Server-Traps)
• Regeln brechen,
• Corporate Warfare,
• Extremer Zeitdruck

Als das Hauptproblem hinter den verschiedenen Inkonsistenzen wurde das Hinzufügen dieser Präsentation, Sitzung oder Interaktivität in der ursprünglichen Vision des Webs nie erwartet. Einige Beispiele für Inkonsistenzen sind:

• document.all, eine Microsoft-einzige Funktion,
• die Tatsache, dass nameund idfrüher austauschbar war.
• Die verschiedenen Funktionen zum Abrufen von Knoten:
  
  • document.getElementById(id),
  • document.getElementsByName(name),
  • *node*.getElementsByTagName(tagName))

und fährt mit ein paar weiteren Beispielen fort, die hauptsächlich das Durchlaufen des DOM, Speicherlecks und das Tröpfeln und Sprudeln von Ereignissen zum Ziel haben. Es gibt eine zusammenfassende Folie mit dem Titel "The Cracks of DOM", die Folgendes zusammenfasst:

• Die DOM-Fehlerliste enthält alle Fehler im Browser.
• Die DOM-Fehlerliste enthält alle Fehler in allen unterstützten Browsern.
• Kein DOM setzt die Standards vollständig um.
• Ein Großteil des DOM ist in keinem Standard beschrieben.

Kurz gesagt, es ist eine chaotische, chaotische API. Es mag wie Nitpicking erscheinen, aber Sie müssen bedenken, dass Sie beim Entwickeln für das Web selten den Browser auswählen müssen, den Ihre Kunden verwenden werden. Es wird sehr bald alt, alles in mindestens zwei Versionen jedes der wichtigsten Browser testen zu müssen . Eine API soll konsistent sein und das DOM war ein Opfer der Browserkriege , aber es wird besser. Es ist immer noch nicht so plattformneutral wie das W3C (und ich denke, wir alle) es gerne hätten, aber die Browser-Anbieter scheinen eher bereit zu sein, zusammenzuarbeiten, als noch vor fünf oder zehn Jahren.

Was ist los mit dem DOM? Abgesehen von der von Java inspirierten Syntax (die Crockford angesprochen hat), nichts.

Was "falsch" ist, gilt teilweise für Browser-Anbieter. Was "falsch" ist, gilt für Entwickler. Was "falsch" ist, gilt für Unwissenheit.

Also, wo soll ich anfangen?

In den Kaninchenbau…

Browser-Anbieter

Zuallererst haben Browser-Anbieter über Jahrzehnte im Wettbewerb darum gekämpft, die "besten", "schnellsten", "einfachsten" usw. zu sein. Im ersten Jahrzehnt (199x-2000) hat Microsoft die Nase vorn. Der Internet Explorer stellte innovative Ideen vor, wie zum Beispiel:

• Offenlegen der HTML-Parsing-Engine des Browsers als innerHTMLund outerHTML;
• einfache textuelle Manipulation mit innerTextund outerText;
• ein Ereignismodell ( *tachEvent), das der Entwurf für DOM Level 2-Ereignisse ( *EventListener) war.

Jeder hat (zum Guten und zum Schlechten) erheblich zum heutigen Webentwicklungsstapel beigetragen. Opera ging sogar so weit, alle drei in Version 7 (2003) zu implementieren.

Netscape hatte jedoch ein eigenes DOM-Ereignismodell ( *EventListener). Im Jahr 2000 wurde es die DOM Level 2 Events-Spezifikation. Safari 1 (2003) hat dieses Modell implementiert. Opera 7 (2003) hat dieses Modell ebenfalls implementiert. Als die Ruinen von Netscape zu Mozilla wurden, übernahm Firefox 1 (2004) das Modell.

Für den ersten Abschnitt des zweiten Jahrzehnts (2000-2004) regierte Microsoft an oberster Stelle. Der Internet Explorer 6 (2001) war zu dieser Zeit mit Abstand der beste Browser. Einer seiner Konkurrenten, Opera 6 (2001), hatte den DOM Level 1 Core ( createElementua ) noch nicht implementiert . Microsoft implementierte ihn in Internet Explorer 4 (1997), bevor die Spezifikation sogar zu einer Empfehlung wurde (1998).

Der zweite Abschnitt des zweiten Jahrzehnts (2004–2010) würde sich für Microsoft jedoch als katastrophal herausstellen. Im Jahr 2003 veröffentlichte Apple Safari 1.0; Im Jahr 2004 beendete Mozilla Firefox 1.0. Microsoft schien auf seinem Thron auf dem Browserberg zu schlafen. Internet Explorer 7 wurde erst 2006 veröffentlicht: eine Lücke von fünf Jahren, die auf das Veröffentlichungsdatum von Internet Explorer 6 zurückgeht. Im Gegensatz zu den Internet Explorer-Versionen 4 bis 6 wurde in Version 7 nur eine geringe Innovation erzielt. DOM-Änderungen waren winzig. Fast zweieinhalb Jahre später wurde Internet Explorer 8 veröffentlicht. Microsoft war aus seinem Schlaf erwacht und bemerkte die Verschmelzung, die andere Browser-Anbieter um zahlreiche Webstandards gebildet hatten. Leider war seit der letzten echten Innovation von Microsoft zu viel Zeit vergangen. Unter den Browserverkäufern war eine Bewegung entstanden. Dem W3C sollten neue DOM-Funktionen in Form von Spezifikationen hinzugefügt werden. Die Ideen von Microsoft sind in der Vergangenheit geblieben. Microsofts Eventmodell (*tachEvent) wurde für das DOM Level 2-Ereignismodell vermieden. Internet Explorer hat das Vorgängermodell erst in Version 9 (2011) implementiert, die zum DOM Level 3-Ereignismodell wurde.

Die Follies von Microsoft (DOM) lassen sich wie folgt zusammenfassen:

• Präsenz als Kernfunktion von Windows und die daraus resultierenden Sicherheitsanforderungen auf Betriebssystemebene;

• Vertrauen auf ActiveX für clientseitigen Code;

• Innovation, die nach Version 6 (2001) merkwürdig nachließ.

(Web-Entwickler

Zweitens tragen die Entwickler eine gewisse Schuld. Da das Web weiter auf dem Vormarsch ist, "tüfteln" immer mehr Leute an der Webentwicklung. Dies hatte zu einer Verwässerung des Talents und der Arbeitsmoral geführt. Das Problem liegt jedoch hauptsächlich in der Einstellung. "Schnell erledigen" hat Vorrang vor "Richtig erledigen". Infolgedessen sind unzählige Webseiten nicht mit verschiedenen Browsern kompatibel. Eine der Hauptursachen für diese Inkompatibilität ist das sogenannte "User Agent Sniffing". Obwohl die Praxis heute noch in Gebrauch ist, hat sich herausgestellt, dass sie sowohl fehlerhaft als auch schädlich ist. Opera ging sogar so weit, die User-Agent-Version bei "9.80" in Version 10 (2009) und höher "einzufrieren". Dies sollte verhindern, dass fehlerhafte Skripte beschädigt werden. Eine viel bessere Praxis namens "

Ignoranz

Drittens ist Unwissenheit mein bevorzugter Grund für die Schuld. Unwissenheit in der Tatsache, dass Browser-Anbieter nicht annähernd genug zusammengearbeitet haben, um einheitliche Spezifikationen zu erstellen; Unwissenheit darüber, dass Microsoft Benutzer anderer Browser gemieden hat; Ignoranz in der Tatsache, dass Entwickler entweder zu faul oder zu kurzsichtig sind, um Browser zu durchsuchen (insbesondere solche, die nicht aktuell sind ). Es gibt viele Unterschiede bei APIs und Implementierungen. Die meisten können mit einem vereinfachten und dennoch defensiven Ansatz (basierend auf DOM 0) vermieden werden, zusammen mit zahlreichen Forschungs- und Testarbeiten. Unwissenheit hat zu der Annahme geführt, dass Internet Explorer 6 eine Seuche auf der Erde ist (erinnern Sie sich an die Stelle auf dem bereits erwähnten Browserthron).

Reflexion

Leider ist das DOM nur eine missverstandene API. Viele wollen Steine ​​werfen (über FUD), aber nur wenige möchten ihre Feinheiten lernen. Ein Ergebnis dieser Ignoranz ist die Einführung von DOM- "Selektoren". Das Herzstück des DOM ist eine API zum Bearbeiten von Dokumentbäumen. Tree Traversal sollte für komplexe Probleme in Form eines analysierten Dokuments verwendet werden. Mit der Einführung der DOM Selectors API kann ein Entwickler nun die CSS-Traversal-Engine des Browsers nutzen. Dies ist recht praktisch, verbirgt jedoch die wahre Form eines Dokumentenbaums. Mit "Selektoren" ist das Abrufen von Elementknoten elementar. Im DOM sind jedoch elf andere Knotentypen angegeben. Was ist mit Textknoten? Kommentarknoten? Dokumentknoten? Dies sind auch Knoten, die häufig während der Interaktion mit dem DOM gewünscht werden.

Fazit

Kurz gesagt, nehmen Sie sich Zeit und lesen Sie die verschiedenen DOM-Spezifikationen. Testen Sie den Code in so vielen Browsern wie möglich. Wenden Sie sich an MSDN, wenn sich Internet Explorer merkwürdig verhält. Am häufigsten wird das Verhalten dokumentiert.

(Historische Anekdoten können und können ungenau sein; Ungenauigkeiten können gerne zur Sprache gebracht werden.)

- Matt

DOM ist eine schreckliche API

Das ist FALSCH . DOM ist KEINE schreckliche API.

• Denken Sie zunächst daran, dass DOM sprachunabhängig ist. Alle wichtigen Sprachen haben die API implementiert. Dies liegt daran, dass Sie es nicht im Browser verwenden, sondern überall dort, wo Sie sich mit XML befassen müssen.

• Beachten Sie zweitens, dass DOM keine Klassen, sondern Schnittstellen definiert. Dies hat eine sehr wichtige Auswirkung: Sprachen können es so implementieren, wie es ihren Konstrukten und ihrer Philosophie entspricht. Dies befreit alle Sprachen von der Notwendigkeit, bei der Implementierung mit anderen konsistent zu sein.

• Drittens ist DOM eine der beiden Hauptmethoden zum Parsen von XML (andere sind SAX). Abhängig von Ihrem Kontext kann DOM sehr effizient sein.

Was Sie meinen, ist Browser-DOM. Und ich stimme zu, dass sich DOM im Browser "schlecht anfühlt". Ein Grund dafür sind Browser-Inkompatibilitäten. Ich bin jedoch anderer Meinung, dass sie der einzige Grund für den schlechten Ruf von DOM im Browser sind.

• Erstens, wenn Sie darüber nachdenken, ist DOM einer der Bereiche, in denen diese Inkompatibilitäten relativ einfach zu überwinden sind. Im Vergleich dazu sind Ereignisse zum Beispiel viel nerviger und nerviger zu normalisieren.

• Zweitens ist die Feature-Erkennung für DOM-Features einfacher als für andere Bereiche.

• Drittens ist DOM 3 viel besser - und heute unterstützen alle Browser das meiste davon.

Inkompatibilitäten sind sicherlich ärgerlich, aber wenn Sie sich darum kümmern, ist DOM viel weniger irritierend.

Ich bin auch nicht einverstanden damit, dass Gründe wie proprietäre Fallen, Corporate Warfare usw. der Grund dafür sind.

• Ich denke, es ist die Trennung zwischen der Philosophie, dass JavaScript eine leichtgewichtige Sprache ist, und der Implementierung von DOM, die von Java inspiriert ist - was zu einem großen Teil der Frustration beigetragen hat.

• Zweitens wurde DOM für XML entwickelt und für HTML angepasst. Daher haben wir im Browser genau zwei DOMs - HTML-DOM und XML-DOM - und sie sind nicht kompatibel.

• Drittens ist die DOM-Überquerung im Browser nicht gut. Wir haben kein XPath für HTML DOM, daher war es vor CSS-Auswahl-Engines sehr mühsam, Traversen durchzuführen.

Schließlich glaube ich, dass heutzutage mit den modernen Browsern (und mit älteren Browsern, die langsam verblassen) kein Grund besteht, DOM als schlecht zu bezeichnen. Im Browser wird es sicherlich besser - sowohl in der API als auch in der Implementierung.