Análise

O Document Object Model, ou DOM, é a representação em memória que um navegador cria depois de ter analisado um documento HTML. Lá onde o HTML que escreve é apenas texto — um fluxo de carateres com parênteses angulares —, o DOM é uma árvore estruturada de objetos composta por elementos, atributos e nós de texto. É a forma viva e manipulável da sua página que existe dentro do navegador enquanto o utilizador a olha.

Do texto a uma árvore de nós

A transformação do texto em árvore ocorre durante a análise. Quando o navegador lê o seu HTML, cada etiqueta torna-se um nó, e o aninhamento do seu markup torna-se a estrutura pai-filho da árvore. Um parágrafo dentro de uma secção torna-se um nó portador de texto dentro de um nó de elemento dentro de outro nó de elemento, e assim por diante, refletindo fielmente a forma como escreveu o documento. É sobre esta árvore, e não sobre o texto original, que opera o resto da maquinaria do navegador.

O JavaScript interage com a página exclusivamente através desta árvore. APIs como document.querySelector permitem aos scripts encontrar nós, ao passo que métodos como element.appendChild, element.remove ou a atribuição de element.textContent lhes permitem modificar a forma e o conteúdo da árvore. O ponto crucial é que modificar o DOM é o que atualiza aquilo que o utilizador vê, e isso faz-se sem recarregar a página — é o mecanismo por trás de toda a interface dinâmica na web.

Código-fonte, DOM e píxeis não são a mesma coisa

É útil manter distintamente em mente três ideias separadas. Primeiro, há o código-fonte HTML que escreve e guarda num ficheiro. Segundo, há o DOM que o navegador constrói a partir desse código-fonte, depois de ter aplicado as regras de análise e de recuperação de erros do padrão. Terceiro, há os píxeis renderizados que o utilizador vê realmente no ecrã. Estão ligados mas não são idênticos, e confundi-los é uma fonte frequente de frustração na depuração.

O desvio entre o código-fonte e o DOM é mais do que académico, porque o analisador nem sempre produz a árvore que espera ingenuamente. A recuperação de erros padronizada do HTML faz com que o navegador corrija em silêncio as etiquetas não fechadas, reordene os elementos mal colocados e insira os nós que a especificação exige, como um tbody em falta dentro de uma tabela. Em consequência, aquilo que vê nas ferramentas de programação do navegador é o DOM depois destas correções, que pode diferir do markup em bruto que escreveu.

Por que a árvore viva se afasta do ficheiro

Porque os scripts leem e escrevem o DOM em vez do texto original, a árvore viva pode afastar-se muito do ficheiro que escreveu. Uma aplicação de página única pode carregar um documento HTML quase vazio e depois construir a maior parte da sua interface inteiramente em JavaScript, de modo que o DOM diante do utilizador se pareça pouco com o código-fonte que o navegador recebeu ao início. Inspecionar o DOM vivo, e não o código-fonte da página, é, portanto, a forma fiável de ver o estado atual.

Os frameworks assentam na mesma árvore

Os frameworks modernos são construídos por cima deste mesmo DOM em vez de o substituírem. Bibliotecas como o React mantêm a sua própria descrição de como a interface deveria parecer e calculam o conjunto mínimo de alterações necessárias para pôr o DOM real em conformidade, aplicando essas atualizações de forma eficiente. Seja qual for a abstração colocada por cima, o navegador renderiza em definitivo a partir de uma única árvore DOM partilhada, o que explica por que compreendê-lo compensa qualquer que seja o seu framework.

Compreender o DOM esclarece também conceitos adjacentes que de outro modo parecem desligados. As ferramentas de acessibilidade leem o DOM para expor o conteúdo às tecnologias de apoio; os validadores verificam se o seu markup produz uma árvore conforme; e o CSS é aplicado aos nós do DOM para determinar como se apresentam. Cada um destes elementos só ganha sentido quando vê o DOM como o objeto central no qual tudo o resto lê ou escreve.

A chave de abóbada da stack front-end

As considerações de desempenho decorrem do mesmo modelo. Porque as alterações feitas ao DOM podem levar o navegador a recalcular o layout e a repintar, efetuar numerosas pequenas atualizações dispersas pode ser lento, o que explica em parte por que os frameworks agrupam as suas alterações. Saber que o DOM é a coisa que é mutada — e que mutá-la tem um custo — é a base para raciocinar sobre o motivo por que certas interfaces parecem reativas e outras aos solavancos.

Visto assim, o DOM é a chave de abóbada da stack front-end: uma árvore produzida por um analisador a partir do seu HTML, manipulada por script, formatada pelo CSS, e renderizada em píxeis. Apreendê-lo como uma única estrutura viva na qual tudo lê e escreve é o fundamento para compreender como a validação, a acessibilidade, os frameworks e a renderização se encaixam todos. Uma vez que o DOM se assenta na sua mente, grande parte do resto do desenvolvimento web deixa de parecer magia e começa a parecer-se com um sistema sobre o qual pode raciocinar.