Quel est le problème avec le DOM?

J'entends toujours 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?

Crockford a donné une présentation détaillée intitulée "Une API peu pratique: la théorie du 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 agaçante à propos du DOM. Il identifie:

• Pièges propriétaires (navigateur et serveur),
• Briser la règle,
• Guerre d'entreprise,
• Temps extrême pression

En tant que principaux problèmes à l'origine des diverses incohérences, l'ajout d'une présentation, d'une session ou d'une interactivité n'a jamais été anticipé dans la vision d'origine du Web. Voici quelques exemples d'incohérences:

• document.all, une fonctionnalité uniquement Microsoft,
• le fait que nameet idétait interchangeable.
• les différentes fonctions sur la récupération des nœuds:
  
  • document.getElementById(id),
  • document.getElementsByName(name),
  • *node*.getElementsByTagName(tagName))

et continue avec quelques exemples supplémentaires, ciblant principalement la traversée du DOM, les fuites de mémoire et le ruissellement d’événement. Il existe une diapositive récapitulative intitulée "The Cracks of DOM" qui résume:

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

En bref, c'est une API en désordre, en désordre. Cela peut sembler ridicule, mais vous devez garder à l’esprit que, lorsque vous vous développez pour le Web, vous devez rarement choisir le navigateur que vos clients utiliseront. Devoir tout tester dans au moins deux versions de chacun des principaux navigateurs vieillit très vite. Une API est supposée être cohérente et le DOM a été victime de la guerre des navigateurs , mais sa situation s'améliore. La plate-forme n’est toujours pas aussi neutre que le W3C (et je pense que nous le souhaitons tous), mais les éditeurs de navigateurs semblent bien plus désireux de coopérer qu’il ne l’était il ya cinq ou dix ans.

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

Ce qui est "faux" s'applique partiellement aux vendeurs 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…

Navigateurs Vendeurs

Tout d'abord, les éditeurs de navigateurs se sont battus pendant des décennies pour devenir les «meilleurs», les «plus rapides», les «plus faciles», etc. Au cours de la première décennie (199x-2000), Microsoft a fait la loi. Internet Explorer a introduit des idées innovantes telles que:

• exposer le moteur d'analyse HTML du navigateur en tant que innerHTMLet outerHTML;
• manipulation textuelle facile avec innerTextet outerText;
• un modèle d'événement ( *tachEvent) qui était le plan directeur pour les événements DOM niveau 2 ( *EventListener).

Chacun a contribué (pour le meilleur et pour le pire) à 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. Lorsque les ruines de Netscape sont devenues Mozilla, Firefox 1 (2004) a hérité du modèle.

Pour 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 à l'époque. Un de ses concurrents, Opera 6 (2001), devait encore implémenter le DOM niveau 1 Core ( createElementet al.) Microsoft l’avait mis en œuvre 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) serait 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 du navigateur. Internet Explorer 7 n’a été commercialisé qu’en 2006: un écart de cinq ans qui remonte à la date de publication d’Internet Explorer 6. Contrairement aux versions 4 à 6 d'Internet Explorer, la version 7 a peu innové; Les changements de DOM étaient minute. Près de deux ans et demi plus tard, Internet Explorer 8 a été publié. Microsoft s'était réveillé de son sommeil et avait remarqué la coalescence que d'autres éditeurs de navigateurs s'étaient formés autour de nombreuses normes Web. Malheureusement, trop de temps s'est écoulé depuis la dernière véritable innovation de Microsoft. Un mouvement avait été créé parmi les éditeurs de navigateurs. De nouvelles fonctionnalités DOM devaient être ajoutées sous forme de spécification au W3C; Les idées de Microsoft ont été laissées dans le passé. Modèle d'événement de Microsoft (*tachEvent) a été évité pour le modèle des événements DOM niveau 2. Internet Explorer n'a pas implémenté le modèle précédent jusqu'à 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é résultantes au niveau du système d'exploitation;

• confiance dans ActiveX pour le code côté client;

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

(Développeurs web

Deuxièmement, les développeurs portent un certain blâme. Alors que le Web continue de prendre son essor, de plus en plus de personnes se "mêlent" au développement Web. Cela avait entraîné une dilution du talent et de l’éthique de travail. Le problème réside toutefois principalement dans l'attitude. "Le faire rapidement" a pris le pas sur "Le faire correctement". 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 "sniffing d'agent d'utilisateur". Bien que la pratique soit encore utilisée aujourd'hui, il a été prouvé qu'elle était à la fois erronée et nuisible. Opera est même allé jusqu'à "figer" la version de l'agent utilisateur à "9.80" dans la version 10 (2009) et au-delà. Cela visait à empêcher la rupture de scripts erronés. Une pratique bien meilleure appelée "

Ignorance

Troisièmement, mon blâme préféré est l’ignorance; l'ignorance sur le fait que les éditeurs de navigateurs ne travaillaient pas assez ensemble pour créer des spécifications unifiées; ignorance du fait que Microsoft a fui les utilisateurs d'autres navigateurs; ignorance du fait que les développeurs sont soit trop paresseux, soit trop myopes pour se permettre de rechercher des navigateurs (en particulier ceux qui ne sont pas en vogue ). Il existe de nombreuses différences dans les API et les implémentations. La plupart peuvent être évités avec une approche à la fois simpliste et défensive (utilisation de DOM 0) ainsi que de nombreuses recherches et tests. L'ignorance a conduit à l'idée qu'Internet Explorer 6 est un fléau pour la Terre (rappelez-vous sa place sur le trône du navigateur mentionné précédemment).

Réflexion

Malheureusement, le DOM est juste une API mal comprise. Beaucoup désirent lancer des pierres (via FUD), mais peu désirent en apprendre plus sur ses subtilités. L’un des résultats de cette ignorance est l’introduction de "sélecteurs" dans le DOM. Le DOM en cœur est une API permettant de manipuler les arborescences de documents. La traversée d’arbres doit être utilisée pour des 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 exploiter le moteur de traversée CSS du navigateur. C'est très pratique, mais cela cache la vraie forme d'un arbre de documents. Avec "sélecteurs", la récupération de nœud d'élément est élémentaire. Cependant, le DOM a onze autres types de nœuds spécifiés. Qu'en est-il des nœuds de texte? Commenter les nœuds? Noeuds de document? Ce sont également des nœuds qui sont souvent souhaités lors d’une interaction avec le DOM.

Conclusion

En bref, prenez votre temps et lisez les différentes spécifications du 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; toutes les inexactitudes sont les bienvenues.)

-Mat

DOM est une API terrible

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

• Tout d’abord, rappelez-vous que DOM est une langue agnostique. Toutes les langues principales ont implémenté l'API. En effet, vous ne l'utilisez tout simplement pas dans un 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 à leur guise. Cela libère toutes les langues de la cohérence de 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, en fonction de votre contexte, DOM peut être très efficace.

Vous parlez du navigateur DOM. Et, je suis d'accord que DOM "se sent" mal dans le navigateur. Une partie de la raison est des incompatibilités de navigateur. Mais je ne suis pas d'accord pour dire qu'ils sont l'unique raison de la mauvaise réputation de DOM dans le navigateur.

• Premièrement, si vous y réfléchissez, DOM est l’un des domaines dans lesquels ces incompatibilités sont relativement plus faciles à surmonter. En comparaison, les événements, par exemple, sont bien plus difficiles et gênants à normaliser.

• Deuxièmement, la détection de 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 supportent l'essentiel.

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

Je suis également en désaccord avec des raisons telles que les pièges exclusifs, la guerre d’entreprise, etc.

• Je pense que c’est la déconnexion entre la philosophie de JavaScript qui est un langage léger et la mise en œuvre de DOM inspirée de Java - qui a largement contribué à la frustration.

• Deuxièmement, DOM a été conçu pour XML et 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 du DOM dans le navigateur n’est pas bonne. Nous n'avons pas XPath pour HTML DOM, alors avant les moteurs de sélecteur CSS, c'était vraiment fastidieux de faire des traversées.

Enfin, je pense qu’aujourd’hui , avec les navigateurs modernes (et que les anciens navigateurs s’affaiblissent lentement), il n’ya aucune raison que DOM doive être qualifié de mauvais. Cela va certainement s'améliorer dans le navigateur - à la fois l'API et la mise en œuvre.