Análisis

¿Qué es el DOM?

• VersionDude
• Análisis
• 5 min de lectura

El Modelo de Objetos del Documento es el árbol que el navegador construye a partir de tu HTML — y aquello con lo que realmente habla tu JavaScript.

El DOM, o Modelo de Objetos del Documento, es la representación en memoria que un navegador crea tras analizar un documento HTML. Mientras que el HTML que escribes es solo texto —un flujo de caracteres con corchetes angulares—, el DOM es un árbol estructurado de objetos formado por elementos, atributos y nodos de texto. Es la forma viva y manipulable de tu página que existe dentro del navegador mientras el usuario la está mirando.

JavaScript interactúa con la página exclusivamente a través de este árbol. APIs como document.querySelector permiten a los scripts encontrar nodos, mientras que métodos como element.appendChild, element.remove o establecer element.textContent les permiten cambiar la forma y el contenido del árbol. El punto crucial es que modificar el DOM es lo que actualiza lo que ve el usuario, y lo hace sin recargar la página: este es el mecanismo detrás de cada interfaz dinámica de la web.

Ayuda mantener tres ideas distintas con claridad en mente. Primero, está el código fuente HTML que escribes y guardas en un archivo. Segundo, está el DOM que el navegador construye a partir de ese código fuente, tras aplicar las reglas de análisis y recuperación de errores del estándar. Tercero, están los píxeles renderizados que el usuario ve realmente en pantalla. Están relacionados pero no son idénticos, y confundirlos es una fuente frecuente de frustración al depurar.

La brecha entre el código fuente y el DOM es más que académica, porque el analizador no siempre produce el árbol que ingenuamente esperas. La recuperación de errores estandarizada del HTML significa que el navegador corregirá en silencio etiquetas sin cerrar, reordenará elementos mal colocados e insertará nodos que la especificación requiere, como un tbody ausente dentro de una tabla. Como resultado, lo que ves en las herramientas para desarrolladores del navegador es el DOM tras estas correcciones, que puede diferir del marcado en bruto que escribiste.

Como los scripts leen y escriben el DOM en lugar del texto original, el árbol vivo puede alejarse mucho del archivo que escribiste. Una aplicación de página única puede cargar un documento HTML casi vacío y luego construir la mayor parte de su interfaz por completo en JavaScript, de modo que el DOM frente al usuario guarda poco parecido con el código fuente que el navegador recibió primero. Inspeccionar el DOM vivo, y no el código fuente de la página, es por tanto la forma fiable de ver el estado actual.

Los frameworks modernos se construyen sobre este mismo DOM en lugar de reemplazarlo. Bibliotecas como React mantienen su propia descripción de cómo debería verse la interfaz y calculan el conjunto mínimo de cambios necesarios para alinear el DOM real, aplicando esas actualizaciones de forma eficiente. Sea cual sea la abstracción que se sitúe encima, el navegador en última instancia renderiza a partir de un único árbol DOM compartido, razón por la cual entenderlo da frutos independientemente de tu framework.

Entender el DOM también clarifica conceptos adyacentes que de otro modo parecen inconexos. Las herramientas de accesibilidad leen el DOM para exponer el contenido a la tecnología de asistencia; los validadores comprueban si tu marcado produce un árbol conforme; y el CSS se aplica a los nodos del DOM para determinar cómo se renderizan. Cada una de estas cosas solo cobra sentido una vez que ves el DOM como el objeto central del que todo lo demás lee o en el que escribe.

Las consideraciones de rendimiento se derivan del mismo modelo. Como los cambios en el DOM pueden hacer que el navegador recalcule el diseño y vuelva a pintar, realizar muchas actualizaciones pequeñas y dispersas puede ser lento, lo que es parte de por qué los frameworks agrupan sus cambios. Saber que el DOM es la cosa que se está mutando —y que mutarla tiene un coste— es la base para razonar por qué algunas interfaces se sienten ágiles y otras dan tirones.

Visto así, el DOM es la clave de bóveda de la pila del front-end: un árbol producido por un analizador a partir de tu HTML, manipulado por scripts, estilizado por CSS y renderizado a píxeles. Captarlo como una única estructura viva de la que todo lee y escribe es la base para entender cómo encajan la validación, la accesibilidad, los frameworks y el renderizado. Una vez que el DOM hace clic, gran parte del resto del desarrollo web deja de sentirse como magia y empieza a sentirse como un sistema sobre el que puedes razonar.