Parsing

Das Document Object Model, kurz DOM, ist die In-Memory-Repräsentation, die ein Browser erstellt, nachdem er ein HTML-Dokument analysiert hat. Wo das HTML, das Sie schreiben, nur Text ist – ein Strom von Zeichen mit spitzen Klammern –, ist das DOM ein strukturierter Baum von Objekten aus Elementen, Attributen und Textknoten. Es ist die lebendige, manipulierbare Form Ihrer Seite, die im Browser existiert, während der Nutzer sie betrachtet.

Vom Text zu einem Baum von Knoten

Die Verwandlung von Text in Baum geschieht während der Analyse. Wenn der Browser Ihr HTML liest, wird jedes Tag zu einem Knoten, und die Verschachtelung Ihres Markups wird zur Eltern-Kind-Struktur des Baums. Ein Absatz innerhalb eines Abschnitts wird zu einem textragenden Knoten innerhalb eines Elementknotens innerhalb eines weiteren Elementknotens und so fort, getreu der Art, wie Sie das Dokument geschrieben haben. Auf diesem Baum, nicht auf dem ursprünglichen Text, arbeitet der Rest der Browser-Maschinerie.

JavaScript interagiert mit der Seite ausschließlich über diesen Baum. APIs wie document.querySelector erlauben Skripten, Knoten zu finden, während Methoden wie element.appendChild, element.remove oder das Zuweisen von element.textContent es ihnen erlauben, Form und Inhalt des Baums zu verändern. Entscheidend ist, dass das Verändern des DOM das aktualisiert, was der Nutzer sieht, und dies ohne Neuladen der Seite – es ist der Mechanismus hinter jeder dynamischen Oberfläche im Web.

Quellcode, DOM und Pixel sind nicht dasselbe

Es hilft, drei getrennte Ideen klar auseinanderzuhalten. Erstens gibt es den HTML-Quellcode, den Sie schreiben und in einer Datei speichern. Zweitens gibt es das DOM, das der Browser aus diesem Quellcode aufbaut, nachdem er die Analyse- und Fehlerwiederherstellungsregeln des Standards angewandt hat. Drittens gibt es die gerenderten Pixel, die der Nutzer tatsächlich auf dem Bildschirm sieht. Sie hängen zusammen, sind aber nicht identisch, und sie zu verwechseln ist eine häufige Quelle von Frust beim Debuggen.

Die Kluft zwischen Quellcode und DOM ist mehr als akademisch, denn der Parser erzeugt nicht immer den Baum, den Sie naiv erwarten. Die standardisierte Fehlerwiederherstellung von HTML bewirkt, dass der Browser nicht geschlossene Tags still korrigiert, falsch platzierte Elemente umordnet und die Knoten einfügt, die die Spezifikation verlangt, etwa ein fehlendes tbody innerhalb einer Tabelle. Folglich ist das, was Sie in den Entwicklerwerkzeugen des Browsers sehen, das DOM nach diesen Korrekturen, das vom rohen Markup, das Sie geschrieben haben, abweichen kann.

Warum der lebendige Baum von der Datei abweicht

Weil Skripte das DOM lesen und schreiben statt den ursprünglichen Text, kann der lebendige Baum weit von der Datei abweichen, die Sie geschrieben haben. Eine Single-Page-Anwendung kann ein nahezu leeres HTML-Dokument laden und dann den Großteil ihrer Oberfläche vollständig in JavaScript aufbauen, sodass das DOM vor dem Nutzer dem Quellcode, den der Browser anfangs erhielt, kaum ähnelt. Das lebendige DOM zu inspizieren, nicht den Quellcode der Seite, ist daher der verlässliche Weg, den aktuellen Zustand zu sehen.

Frameworks bauen auf demselben Baum auf

Moderne Frameworks sind auf eben diesem DOM aufgebaut, statt es zu ersetzen. Bibliotheken wie React pflegen ihre eigene Beschreibung dessen, wie die Oberfläche aussehen sollte, und berechnen die minimale Menge an Änderungen, die nötig sind, um das echte DOM in Übereinstimmung zu bringen, und wenden diese Aktualisierungen effizient an. Welche Abstraktion auch darübergelegt wird, der Browser rendert letztlich aus einem einzigen, geteilten DOM-Baum, weshalb es sich auszahlt, ihn zu verstehen, gleich welches Framework Sie nutzen.

Das DOM zu verstehen klärt auch angrenzende Konzepte, die sonst losgelöst erscheinen. Barrierefreiheitswerkzeuge lesen das DOM, um den Inhalt assistiven Technologien zugänglich zu machen; Validatoren prüfen, ob Ihr Markup einen konformen Baum erzeugt; und CSS wird auf die DOM-Knoten angewandt, um zu bestimmen, wie sie angezeigt werden. Jedes davon ergibt erst Sinn, sobald Sie das DOM als das zentrale Objekt sehen, in das alles andere liest oder schreibt.

Der Schlussstein des Frontend-Stacks

Leistungserwägungen folgen aus demselben Modell. Weil Änderungen am DOM den Browser dazu bringen können, das Layout neu zu berechnen und neu zu zeichnen, kann es langsam sein, viele kleine, verstreute Aktualisierungen vorzunehmen, was zum Teil erklärt, warum Frameworks ihre Änderungen bündeln. Zu wissen, dass das DOM die Sache ist, die mutiert wird – und dass das Mutieren etwas kostet –, ist die Grundlage, um darüber nachzudenken, warum manche Oberflächen reaktionsschnell und andere ruckelig wirken.

So betrachtet ist das DOM der Schlussstein des Frontend-Stacks: ein vom Parser aus Ihrem HTML erzeugter Baum, per Skript manipuliert, durch CSS gestaltet und zu Pixeln gerendert. Es als eine einzige lebendige Struktur zu begreifen, in die alles liest und schreibt, ist das Fundament, um zu verstehen, wie Validierung, Barrierefreiheit, Frameworks und Rendering ineinandergreifen. Sobald sich das DOM in Ihrem Kopf einfügt, hört ein großer Teil der übrigen Webentwicklung auf, wie Magie zu wirken, und beginnt, wie ein System auszusehen, über das Sie nachdenken können.