web-dev-qa-db-fra.com

Qu'est-ce qui est si mauvais avec le DOM?

Je n'arrête pas d'entendre des gens (Crockford en particulier) dire que le DOM est une API terrible, mais ne justifie pas vraiment cette déclaration. Outre les incohérences entre les navigateurs, quelles sont les raisons pour lesquelles le DOM est considéré comme si mauvais?

javascriptapiapi-designdom
43
wheresrhys

Crockford a donné une présentation détaillée intitulée "An Inconvenient API: The Theory of the Dom" où il explique plus ou moins ses opinions sur le DOM. C'est long (1h 18m), mais comme la plupart des présentations de Crockford, c'est assez agréable et instructif.

Les incohérences entre les navigateurs semblent être sa principale préoccupation, et je conviens que c'est la chose la plus ennuyeuse à propos du DOM. Il identifie:

  • Pièges propriétaires (pièges du navigateur et du serveur),
  • Rupture de règle,
  • Guerre d'entreprise,
  • Pression extrême du temps

comme les problèmes clés derrière les diverses incohérences, ajoutant que la présentation, la session ou l'interactivité n'a jamais été anticipée dans la vision originale du Web. Voici quelques exemples d'incohérences:

  • document.all, Une fonctionnalité réservée à Microsoft,
  • le fait que name et id étaient interchangeables.
  • les différentes fonctions de récupération des nœuds:
    • document.getElementById(id),
    • document.getElementsByName(name),
    • *node*.getElementsByTagName(tagName))

et continue avec quelques autres exemples, ciblant principalement la traversée du DOM, les fuites de mémoire et le ruissellement et le bouillonnement des événements. Il y a une diapositive récapitulative, intitulée "Les fissures du DOM" qui résume:

  • La liste de diffusion DOM inclut tous les bogues du navigateur.
  • La liste de diffusion DOM inclut tous les bogues de tous les navigateurs pris en charge.
  • Aucun DOM n'implémente complètement les normes.
  • Une grande partie du DOM n'est décrite dans aucune norme.

En bref, c'est une API désordonnée et désordonnée. Cela peut sembler compliqué, mais vous devez garder à l'esprit que lorsque vous développez pour le Web, vous choisissez rarement le navigateur que vos clients utiliseront. Devoir tout tester dans au moins deux versions de chacun des principaux navigateurs vieillit très bientôt. Une API est censée être cohérente et le DOM a été victime des guerres du navigateur , mais ça va mieux. Ce n'est toujours pas aussi neutre sur la plate-forme que le W3C (et je pense que nous tous) le souhaiterions, mais les fournisseurs de navigateurs semblent beaucoup plus désireux de coopérer qu'il y a cinq ou dix ans.

34
yannis

Quel est le problème avec le DOM? Mis à part la syntaxe inspirée de Java (dont Crockford a parlé), rien.

Ce qui est "faux" s'applique partiellement aux fournisseurs de navigateurs; ce qui est "faux" s'applique aux développeurs; ce qui est "faux" s'applique à l'ignorance.

Alors, par où commencer?

Dans le trou de lapin…

Fournisseurs de navigateurs

Tout d'abord, les fournisseurs de navigateurs se sont battus de manière compétitive au cours des décennies pour être les "meilleurs", "les plus rapides", "les plus faciles", etc. Au cours de la première décennie (199x-2000), Microsoft a gouverné le perchoir. Internet Explorer a introduit des idées innovantes telles que:

  • exposer le moteur d'analyse HTML du navigateur comme innerHTML et outerHTML;
  • manipulation textuelle facile avec innerText et outerText;
  • un modèle d'événement (*tachEvent) qui était le modèle des événements DOM de niveau 2 (*EventListener).

Chacun a contribué (pour le meilleur et pour le pire) de manière significative à la pile de développement Web d'aujourd'hui. Opera est même allé jusqu'à implémenter les trois dans la version 7 (2003).

Cependant, Netscape avait son propre modèle d'événement DOM (*EventListener). En 2000, il est devenu la spécification DOM Level 2 Events. Safari 1 (2003) a mis en œuvre ce modèle; Opera 7 (2003) a également implémenté ce modèle. Comme les ruines de Netscape sont devenues Mozilla, Firefox 1 (2004) a hérité du modèle.

Pendant la première partie de la deuxième décennie (2000-2004), Microsoft a régné en maître. Internet Explorer 6 (2001) était de loin le meilleur navigateur de l'époque. L'un de ses concurrents, Opera 6 (2001), n'avait pas encore implémenté le DOM niveau 1 Core (createElement et al.) Microsoft l'a implémenté dans Internet Explorer 4 (1997) avant même que la spécification ne devienne une recommandation (1998).

Cependant, la deuxième partie de la deuxième décennie (2004-2010) s'avérerait désastreuse pour Microsoft. En 2003, Apple a publié Safari 1.0; en 2004, Mozilla a terminé Firefox 1.0. Microsoft était apparemment endormi sur son trône au sommet de la montagne des navigateurs. Internet Explorer 7 n'est pas sorti avant 2006: un écart de cinq années remontant à la date de sortie d'Internet Explorer 6. Contrairement aux versions 4 à 6 d'Internet Explorer, la version 7 a peu innové; les changements DOM ont été infimes. Près de deux ans et demi plus tard, Internet Explorer 8 a été publié. Microsoft s'est réveillé de son somnolence et a remarqué la coalescence d'autres fournisseurs de navigateurs s'étaient formés autour de nombreuses normes Web. Malheureusement, trop de temps s'était écoulé depuis la dernière véritable innovation de Microsoft. Un mouvement avait été créé parmi les fournisseurs de navigateurs. De nouvelles fonctionnalités DOM devaient être ajoutées sous forme de spécifications au W3C ; Les idées de Microsoft ont été laissées dans le passé. Le modèle d'événement de Microsoft (*tachEvent) a été évité pour le modèle DOM Level 2 Events. Internet Explorer n'a pas implémenté le modèle précédent avant la version 9 (2011), qui est devenue le modèle DOM Level 3 Events.

Les folies de Microsoft (DOM) peuvent être résumées par les points suivants:

  • la présence en tant que fonctionnalité principale de Windows et les exigences de sécurité au niveau du système d'exploitation qui en résultent;

  • la dépendance à ActiveX pour le code côté client;

  • innovation qui s'est effondrée curieusement après la version 6 (2001).

Développeurs (Web)

Deuxièmement, les développeurs portent un certain blâme. Alors que le Web a continué de décoller, de plus en plus de gens "barbotent" dans le développement Web. Cela avait conduit à une dilution du talent et de l'éthique de travail. Cependant, le problème réside principalement dans l'attitude. "Get it done quick" a pris le pas sur "Get it done right". En conséquence, d'innombrables pages Web sont incompatibles avec divers navigateurs. L'une des principales causes de cette incompatibilité est une pratique appelée "reniflement d'agent utilisateur". Bien que la pratique soit toujours utilisée aujourd'hui, elle s'est avérée à la fois erronée et nuisible. Opera est même allé jusqu'à "geler" la version de l'agent utilisateur à "9.80" dans la version 10 (2009) et au-delà. Cela visait à empêcher les scripts erronés de se casser. Une bien meilleure pratique appelé "test de fonctionnalité" (bien que sous une forme principalement naïve pour le moment) a été adopté par les développeurs.

Ignorance

Troisièmement, mon point de culpabilité préféré est l'ignorance; l'ignorance du fait que les fournisseurs de navigateurs ne travaillaient pas assez ensemble pour créer des spécifications unifiées; l'ignorance du fait que Microsoft a évité les utilisateurs d'autres navigateurs; l'ignorance du fait que les développeurs sont soit trop paresseux soit trop myopes pour déranger les recherches sur les navigateurs (en particulier ceux qui ne sont pas en vogue .) Il existe de nombreuses différences dans API et implémentations. La plupart peuvent être évités avec une approche simplifiée mais défensive (dépendance à DOM 0) avec des quantités abondantes de recherches et de tests. L'ignorance a conduit à l'idée qu'Internet Explorer 6 est un fléau sur la Terre (rappelez-vous sa place sur le trône du navigateur mentionné plus tôt.)

Réflexion

Malheureusement, le DOM n'est qu'une API mal comprise. Beaucoup désirent lancer des pierres (via FUD), mais peu désirent en apprendre les subtilités. Un résultat de cette ignorance est l'introduction de "sélecteurs" DOM. Le DOM dans l'âme est une API pour manipuler les arbres de documents. La traversée d'arbre doit être utilisée pour les problèmes complexes étant donné la forme d'un document analysé. Avec l'introduction de l'API DOM Selectors, un développeur peut désormais tirer parti du moteur de traversée CSS du navigateur. C'est assez pratique, mais cela cache la vraie forme d'une arborescence de documents. Avec les "sélecteurs", la récupération des nœuds d'élément est élémentaire. Cependant, le DOM a onze autres types de nœuds spécifiés. Et les nœuds de texte? Noeuds de commentaire? Noeuds de document? Ce sont également des nœuds qui sont souvent souhaités lors de l'interaction avec le DOM.

Conclusion

En bref, prenez votre temps et lisez les différentes spécifications DOM. Testez le code dans autant de navigateurs que possible. Si Internet Explorer est perçu comme se comportant bizarrement, consultez MSDN. Le plus souvent, le comportement est documenté.

(Les anecdotes historiques peuvent et peuvent être inexactes; toute inexactitude peut être soulevée.)

-Mat

16
null

DOM est une terrible API

C'est FAUX . DOM n'est pas une API terrible.

  • Tout d'abord, rappelez-vous que DOM est indépendant du langage. Toutes les langues principales ont implémenté l'API. C'est parce que vous ne l'utilisez tout simplement pas dans le navigateur, mais partout où vous devez traiter avec XML.

  • Deuxièmement, notez que DOM ne définit pas les classes mais les interfaces. Cela a une implication très importante: les langages peuvent l'implémenter comme il convient à leurs constructions et à leur philosophie. Cela évite à toutes les langues d'être cohérentes dans la mise en œuvre avec les autres.

  • Troisièmement, DOM est l'un des deux principaux moyens d'analyser XML (l'autre étant SAX), et selon votre contexte, DOM peut être très efficace.

Vous faites référence au DOM du navigateur. Et, je suis d'accord que DOM "se sent" mal dans le navigateur. Une partie de la raison est les incompatibilités du navigateur. Mais, je ne suis pas d'accord pour dire qu'ils sont la seule raison de la mauvaise réputation de DOM dans le navigateur.

  • Tout d'abord, si vous y réfléchissez, DOM est l'un de ces domaines où ces incompatibilités sont relativement plus faciles à surmonter. En comparaison, les événements, par exemple, sont beaucoup plus délicats et ennuyeux à normaliser.

  • Deuxièmement, la détection des fonctionnalités pour les fonctionnalités DOM est plus simple que pour les autres zones.

  • Troisièmement, DOM 3 est bien meilleur - et aujourd'hui, tous les navigateurs en prennent en charge la plupart.

Certes, les incompatibilités sont gênantes, mais quand vous y arrivez, DOM est beaucoup moins irritant.

Je suis également en désaccord avec des raisons comme les pièges exclusifs, la guerre d'entreprise, etc. en étant la raison.

  • Je pense que c'est la déconnexion entre la philosophie de JavaScript étant un langage léger et l'implémentation de DOM inspirée de Java - qui a contribué à une grande partie de la frustration.

  • Deuxièmement, DOM a été conçu pour XML, et il a été adapté pour HTML. Par conséquent, dans le navigateur, nous avons exactement deux DOM - HTML DOM et XML DOM - et ils sont incompatibles.

  • Troisièmement, la traversée DOM dans le navigateur n'est pas bonne. Nous n'avons pas XPath pour HTML DOM, donc avant les moteurs de sélection CSS, c'était vraiment fastidieux de faire des traversées.

Enfin, je pense que aujourd'hui, avec les navigateurs modernes, (et avec les navigateurs plus anciens qui disparaissent lentement), il n'y a aucune raison que DOM doive être appelé mauvais. Cela va certainement s'améliorer dans le navigateur - à la fois l'API et la mise en œuvre.

4
treecoder