frontend-101
GitHub
The DOM
Responsiveness
Components
State
API Calls
Frameworks
Accessibility
Responsiveness

frontend-101 — a learning resource for new frontend devs.

© 2026 · MIT LicenseFound an issue?

The DOM

The live tree the browser builds from your HTML.

What is the DOM?

The DOM (Document Object Model) is the live tree of objects the browser builds from your HTML and holds in memory. When a page loads, the browser reads your markup once and turns it into a structure it can change on the fly. Every element becomes a node, an object in that tree, and the nesting in your HTML becomes parent-and-child links between nodes: a <p> inside a <div> is a child of that div node.

Here is what trips people up: that live tree and your HTML file are not the same thing. The file is read once to build the tree and then set aside. Everything after that happens in the DOM. A row you add in JavaScript shows up on screen instantly, while the HTML on disk still shows the empty list you first shipped. Right-click a busy page, choose View Source, and hunt for something you can plainly see on screen. If JavaScript put it there, it is not in the source at all.

A useful way to picture it: your HTML is a printed recipe and the DOM is the plated dish on the table. The recipe is written once and never changes on the page. The dish is what people actually eat, and the cook (your JavaScript) keeps adjusting it after it leaves the kitchen, adding a garnish here, swapping a side there. The recipe card on the counter never updates to match.

Why it matters

The DOM is the bridge between your code and what a user sees on screen. Every UI framework, from React to Svelte, ultimately reads and writes the DOM; once you can picture the tree, you have a model for why an interface behaves the way it does and where to reach in to change it.

Miss that model and the everyday work turns into guesswork: selecting the right element, walking up to its parent, dropping a new node in the right place. The problems below are the ones that bite first.

Gone on reload

Add a row with JavaScript and it appears at once. Reload the page and it has vanished. The DOM changed; the file it was built from never did, so nothing survived the refresh.

Grab the wrong node

Target the wrong element and your click handler runs on nothing, silently.

Slow when it's sloppy

Every change to the tree makes the browser re-check what to draw. A handful of edits costs nothing. Rebuild the whole list on every keystroke and the page starts to stutter under the user's fingers.

Interactive demo

Before you touch it: if you delete the <div>, what happens to the <p> and <span> nested inside it? Click a node to inspect it, add or remove nodes, and watch the panels below compare the HTML you wrote against the live DOM.

  • <html>
    • <body>
      • <h1>Hello!
      • <div>
        • <p>First paragraph
        • <span>Styled text

Node Inspector

Click a node to inspect it

The source is the HTML you wrote — it never changes. The live DOM is what the browser renders right now. Lines only in the source are red — removed from the live DOM. Lines only in the live DOM are green — added since the source was written.

Source HTML
<html>
<body>
<h1>Hello!</h1>
<div>
<p>First paragraph</p>
<span>Styled text</span>
</div>
</body>
</html>
Live DOM
<html>
<body>
<h1>Hello!</h1>
<div>
<p>First paragraph</p>
<span>Styled text</span>
</div>
</body>
</html>
Source HTML
<html>
<body>
<h1>Hello!</h1>
<div>
<p>First paragraph</p>
<span>Styled text</span>
</div>
</body>
</html>
Live DOM
<html>
<body>
<h1>Hello!</h1>
<div>
<p>First paragraph</p>
<span>Styled text</span>
</div>
</body>
</html>

Try breaking it:

  • Delete the <div>. The live DOM drops it and everything nested inside, so why does the Source panel turn red over those lines instead of simply removing them?
  • Add a <button> under <body>. It shows up green in the live DOM and never appears in the Source, because the Source is frozen at what you first wrote.
  • Select a node, add a child to it, then select its parent and watch children climb by one in the inspector.

How it works

The tree on the left is the DOM. Click any node to open the inspector, which reports the same properties the browser hands your JavaScript. Type a tag name and optional text to add a child to the selected node, or use the × to remove one. The two panels underneath hold the frozen source next to the live DOM, the recipe held up against the actual plate, so you can see exactly where they have drifted apart.

  • tagName: the element’s HTML tag (e.g. div, h1)
  • children: how many child nodes the element contains
  • textContent: the text inside the element, if any
  • parentNode: which node is one level up in the tree

Notice that the source panel never moved, no matter how much you edited. That is the whole point: your HTML is read once to build the tree, and every edit after that lives in the DOM alone. The browser renders the tree, not the file.

Writing those tree edits by hand gets tedious fast, which is the job frameworks like React take over for you, a story the Frameworks page picks up.

If you remember one thing

The DOM is not the HTML you wrote; it’s what the browser actually renders, and what your code changes.