What actually is the DOM?
I had a fundamental misunderstanding of how webpages worked. I used to think that when I wrote JavaScript to change a button's colour, my code was somehow reaching into my index.html file and rewriting the text. (yes, really). Obviously, that’s not what happens. Once your server sends the HTML file over the network to the user's browser, that file is done.
If you’ve done any backend work, you know what happens when an API receives a JSON payload. It comes over the wire as a raw string. You can’t easily loop through a string to find a specific user ID. You convert that string into a native object loaded into the server's memory. The DOM is the exact same concept, just for the browser. The browser downloads your raw HTML string, parses it, and creates a massive, living data structure in its memory.
Why a Tree?
HTML is inherently nested. An <html> tag contains a <body>, which contains a <div>, which contains a <p>. The browser models this exact hierarchy using a Tree data structure. Every single HTML tag becomes a "node" in this tree. This tree is the DOM. It is a representation of your document, built out of objects, modelled as a tree.
The DOM is actually a Web API provided by the browser. In Chrome, the DOM is implemented in C++ under the hood. Browser give you a global object called document. If you call methods on document, Browser lets you read or update the C++ tree.
const button = document.querySelector('.submit-btn');
button.style.backgroundColor = 'red';
You are writing JavaScript, but you are interacting with the browser's DOM API to change the state of a node in its memory tree.
Why is the DOM slow?
If you've been around frontend tooling for a while, you've probably heard the phrase, "The DOM is slow. That's why we need React and the Virtual DOM." That phrase is actually a half-truth. Updating a node in the DOM is incredibly fast. Remember, it's just updating an object in memory. If you change a button's color in the DOM, that memory update takes less than a fraction of a millisecond.
The DOM isn't slow. Rendering is slow.
When you change something in the DOM tree, the browser engine realizes the tree has mutated. It now has to figure out what that change means for the pixels on the screen.
It has to recalculate the CSS.
It has to figure out the geometry of the page changing this text make the button wider? Did that push the image below it down? (This is called a Reflow or Layout).
Finally, it has to physically draw the new pixels on the screen (This is called a Repaint.
Reflows and repaints are mathematically expensive. If you have a list of 1,000 items and you write a JavaScript for loop that updates them one by one, you trigger that expensive render pipeline 1,000 times in a row. The browser will freeze.
ools like React introduced the Virtual DOM to solve this. They do all the heavy calculations in a lightweight JavaScript copy of the tree, figure out the absolute bare minimum number of changes needed, and then update the real DOM in one big batch. They optimize the writes to avoid triggering the browser's slow render pipeline too many times.
Wrapping up
Whenever you are building for the web, keep the system architecture in your head -
HTML: The raw string payload sent over the wire.
The DOM: The tree of objects the browser builds in memory from that string.
JavaScript: The language we use to tell the browser how to update that tree.