Analyse

Qu'est-ce que le DOM ?

• VersionDude
• Analyse
• 5 min de lecture

Le Document Object Model est l'arbre qu'un navigateur construit à partir de votre HTML — et ce à quoi votre JavaScript parle réellement.

Le Document Object Model, ou DOM, est la représentation en mémoire qu'un navigateur crée après avoir analysé un document HTML. Là où le HTML que vous écrivez n'est que du texte — un flux de caractères avec des chevrons — le DOM est un arbre structuré d'objets composé d'éléments, d'attributs et de nœuds de texte. C'est la forme vivante et manipulable de votre page qui existe à l'intérieur du navigateur pendant que l'utilisateur la regarde.

JavaScript interagit avec la page exclusivement à travers cet arbre. Des API comme document.querySelector permettent aux scripts de trouver des nœuds, tandis que des méthodes comme element.appendChild, element.remove ou l'affectation de element.textContent leur permettent de modifier la forme et le contenu de l'arbre. Le point crucial est que modifier le DOM est ce qui met à jour ce que l'utilisateur voit, et cela se fait sans recharger la page — c'est le mécanisme derrière toute interface dynamique sur le web.

Il est utile de garder distinctement à l'esprit trois idées séparées. Premièrement, il y a le code source HTML que vous écrivez et enregistrez dans un fichier. Deuxièmement, il y a le DOM que le navigateur construit à partir de ce code source, après avoir appliqué les règles d'analyse et de récupération d'erreurs du standard. Troisièmement, il y a les pixels rendus que l'utilisateur voit réellement à l'écran. Ils sont liés mais non identiques, et les confondre est une source fréquente de frustration au débogage.

L'écart entre le code source et le DOM est plus qu'académique, car l'analyseur ne produit pas toujours l'arbre que vous attendez naïvement. La récupération d'erreurs standardisée du HTML fait que le navigateur corrige silencieusement les balises non fermées, réordonne les éléments mal placés et insère les nœuds que la spécification exige, comme un tbody manquant à l'intérieur d'un tableau. En conséquence, ce que vous voyez dans les outils de développement du navigateur est le DOM après ces corrections, ce qui peut différer du balisage brut que vous avez écrit.

Parce que les scripts lisent et écrivent le DOM plutôt que le texte d'origine, l'arbre vivant peut dériver loin du fichier que vous avez écrit. Une application monopage peut charger un document HTML presque vide puis construire la majeure partie de son interface entièrement en JavaScript, de sorte que le DOM devant l'utilisateur ressemble peu au code source que le navigateur a reçu au départ. Inspecter le DOM vivant, et non le code source de la page, est donc le moyen fiable de voir l'état actuel.

Les frameworks modernes sont bâtis par-dessus ce même DOM plutôt que de le remplacer. Des bibliothèques comme React maintiennent leur propre description de ce à quoi l'interface devrait ressembler et calculent l'ensemble minimal de changements nécessaires pour mettre le DOM réel en conformité, appliquant ces mises à jour de manière efficace. Quelle que soit l'abstraction posée au-dessus, le navigateur rend en définitive à partir d'un unique arbre DOM partagé, ce qui explique pourquoi le comprendre est payant quel que soit votre framework.

Comprendre le DOM clarifie aussi des concepts adjacents qui, autrement, semblent déconnectés. Les outils d'accessibilité lisent le DOM pour exposer le contenu aux technologies d'assistance ; les validateurs vérifient si votre balisage produit un arbre conforme ; et le CSS est appliqué aux nœuds du DOM pour déterminer comment ils s'affichent. Chacun de ces éléments ne prend sens qu'une fois que vous voyez le DOM comme l'objet central dans lequel tout le reste lit ou écrit.

Les considérations de performance découlent du même modèle. Parce que les changements apportés au DOM peuvent amener le navigateur à recalculer la mise en page et à repeindre, effectuer de nombreuses petites mises à jour dispersées peut être lent, ce qui explique en partie pourquoi les frameworks regroupent leurs changements. Savoir que le DOM est la chose qui est mutée — et que la muter a un coût — est la base pour raisonner sur les raisons pour lesquelles certaines interfaces semblent réactives et d'autres saccadées.

Vu ainsi, le DOM est la clé de voûte de la pile front-end : un arbre produit par un analyseur à partir de votre HTML, manipulé par script, mis en forme par CSS, et rendu en pixels. Le saisir comme une unique structure vivante dans laquelle tout lit et écrit est le fondement pour comprendre comment la validation, l'accessibilité, les frameworks et le rendu s'imbriquent tous. Une fois que le DOM se met en place dans votre esprit, une grande partie du reste du développement web cesse de ressembler à de la magie et commence à ressembler à un système sur lequel vous pouvez raisonner.