Parsing

Il Document Object Model, o DOM, è la rappresentazione in memoria che un browser crea dopo aver analizzato un documento HTML. Là dove l'HTML che scrivi è solo testo — un flusso di caratteri con parentesi angolari —, il DOM è un albero strutturato di oggetti composto da elementi, attributi e nodi di testo. È la forma viva e manipolabile della tua pagina che esiste all'interno del browser mentre l'utente la guarda.

Dal testo a un albero di nodi

La trasformazione dal testo all'albero avviene durante l'analisi. Quando il browser legge il tuo HTML, ogni tag diventa un nodo, e l'annidamento del tuo markup diventa la struttura genitore-figlio dell'albero. Un paragrafo all'interno di una sezione diventa un nodo portatore di testo all'interno di un nodo elemento all'interno di un altro nodo elemento, e così via, riflettendo fedelmente il modo in cui hai scritto il documento. È su questo albero, e non sul testo originale, che opera il resto della macchineria del browser.

JavaScript interagisce con la pagina esclusivamente attraverso questo albero. API come document.querySelector permettono agli script di trovare nodi, mentre metodi come element.appendChild, element.remove o l'assegnazione di element.textContent permettono loro di modificare la forma e il contenuto dell'albero. Il punto cruciale è che modificare il DOM è ciò che aggiorna quello che l'utente vede, e ciò avviene senza ricaricare la pagina — è il meccanismo dietro ogni interfaccia dinamica sul web.

Codice sorgente, DOM e pixel non sono la stessa cosa

È utile tenere a mente distintamente tre idee separate. Primo, c'è il codice sorgente HTML che scrivi e salvi in un file. Secondo, c'è il DOM che il browser costruisce a partire da quel codice sorgente, dopo aver applicato le regole di analisi e di recupero degli errori dello standard. Terzo, ci sono i pixel renderizzati che l'utente vede realmente sullo schermo. Sono collegati ma non identici, e confonderli è una fonte frequente di frustrazione nel debug.

Lo scarto tra il codice sorgente e il DOM è più che accademico, perché l'analizzatore non produce sempre l'albero che ti aspetti ingenuamente. Il recupero degli errori standardizzato dell'HTML fa sì che il browser corregga in silenzio i tag non chiusi, riordini gli elementi mal collocati e inserisca i nodi che la specifica esige, come un tbody mancante all'interno di una tabella. Di conseguenza, ciò che vedi negli strumenti di sviluppo del browser è il DOM dopo queste correzioni, che può differire dal markup grezzo che hai scritto.

Perché l'albero vivo si discosta dal file

Poiché gli script leggono e scrivono il DOM anziché il testo originale, l'albero vivo può discostarsi molto dal file che hai scritto. Un'applicazione a pagina singola può caricare un documento HTML quasi vuoto e poi costruire la maggior parte della sua interfaccia interamente in JavaScript, così che il DOM davanti all'utente somigli poco al codice sorgente che il browser ha ricevuto all'inizio. Ispezionare il DOM vivo, e non il codice sorgente della pagina, è dunque il modo affidabile per vedere lo stato attuale.

I framework si basano sullo stesso albero

I framework moderni sono costruiti al di sopra di questo stesso DOM anziché sostituirlo. Librerie come React mantengono la propria descrizione di come l'interfaccia dovrebbe apparire e calcolano l'insieme minimo di modifiche necessarie per mettere il DOM reale in conformità, applicando quegli aggiornamenti in modo efficiente. Qualunque astrazione sia posta al di sopra, il browser renderizza in definitiva a partire da un unico albero DOM condiviso, il che spiega perché comprenderlo paga qualunque sia il tuo framework.

Comprendere il DOM chiarisce anche concetti adiacenti che altrimenti sembrano scollegati. Gli strumenti di accessibilità leggono il DOM per esporre il contenuto alle tecnologie assistive; i validatori verificano se il tuo markup produce un albero conforme; e il CSS viene applicato ai nodi del DOM per determinare come si visualizzano. Ciascuno di questi elementi acquista senso solo una volta che vedi il DOM come l'oggetto centrale in cui tutto il resto legge o scrive.

La chiave di volta dello stack front-end

Le considerazioni sulle prestazioni discendono dallo stesso modello. Poiché le modifiche apportate al DOM possono portare il browser a ricalcolare il layout e a ridipingere, effettuare numerosi piccoli aggiornamenti sparsi può essere lento, il che spiega in parte perché i framework raggruppano le loro modifiche. Sapere che il DOM è la cosa che viene mutata — e che mutarla ha un costo — è la base per ragionare sul motivo per cui certe interfacce sembrano reattive e altre a scatti.

Visto così, il DOM è la chiave di volta dello stack front-end: un albero prodotto da un analizzatore a partire dal tuo HTML, manipolato via script, messo in forma dal CSS, e renderizzato in pixel. Coglierlo come un'unica struttura viva in cui tutto legge e scrive è il fondamento per comprendere come la validazione, l'accessibilità, i framework e il rendering si incastrino tutti. Una volta che il DOM si sistema nella tua mente, gran parte del resto dello sviluppo web smette di sembrare magia e comincia a somigliare a un sistema su cui puoi ragionare.