What is "The Dom Api" about?

The DOM is a memory structure, not the HTML file. The DOM API is how JavaScript talks to it. Understanding this changes how you think about rendering performance.

What topics does "The Dom Api" cover?

This article covers: dom api, document object model, javascript dom, window object, dom manipulation, browser rendering.

The Dom Api

Before writing a single line of vanilla JavaScript that changes the page, I had to get one thing straight: the DOM is not the HTML file, and the DOM API is not the DOM. These three things, the HTML file, the DOM, and the DOM API, are distinct layers that get conflated constantly.

The Essentials

The DOM (Document Object Model): A memory structure the browser builds when it parses HTML. It is a tree of objects, one per element, living in RAM.
The DOM API: The set of methods and properties browsers expose so JavaScript can read and modify that memory structure.
The Window object: The global context for all browser JavaScript. Most DOM-related APIs hang off of it.
The Document object: Represents the current page's DOM tree. The starting point for all element queries.
Releasing the thread: DOM changes you make in JavaScript are not painted to the screen until the current function finishes executing. The browser gets its turn only after your code releases the main thread.

The DOM Is Not Your HTML File

When a browser loads a page, it reads the HTML string and parses it into a tree of objects in memory. Each HTML element becomes a JavaScript object. That tree is the DOM.

When I write document.querySelector('h1'), I am not searching through the HTML string. I am looking up an object in that in-memory tree. When I change element.textContent = 'Hello', I am updating that object's property in memory. The change you see on screen is the browser re-rendering from the current state of the tree, not from the original HTML file.

This distinction matters for debugging and performance. The HTML file never changes at runtime. The DOM changes constantly. When you open DevTools and inspect the Elements panel, you are looking at the current DOM state, which may look completely different from the original HTML you shipped.

The DOM API Is Not the DOM

The DOM is the tree in memory. The DOM API is the collection of methods and properties available on that tree so you can interact with it from JavaScript.

The API has been around since the 1990s and has grown substantially since. Today it covers:

Querying elements by ID, class, tag, CSS selector, or position in the tree
Reading and writing element attributes, text content, and HTML structure
Creating, moving, and removing elements
Listening to and dispatching events
Controlling styles, animations, and focus
More specialized APIs added over time: drag and drop, pointer events, intersection observers, resize observers

The MDN documentation lists hundreds of methods and properties across dozens of interfaces. You will realistically use a small fraction of them. But knowing the structure helps when you encounter something unfamiliar.

The Window and Document Objects

When JavaScript runs in a browser, the global object is window. Every global variable, every globally available function, every API the browser exposes, it lives on window. You can access it explicitly (window.alert()) or implicitly (alert()). Both call the same thing.

The window concept comes from the early web, when one browser window meant one page. We have tabs now, and iframes, and the concept is fuzzier. But window is still the root of every global JavaScript environment in the browser.

document is a property of window. It represents the current page's DOM tree. When you call document.querySelector, you are searching the entire document tree starting from the root. When you call document.createElement, you are creating a new element in memory, not yet attached to anything.

Changes Live in Memory Until the Thread Releases

Here is something that trips people up: when you change the DOM in JavaScript, the user does not immediately see the change. The browser only updates what is on screen after your JavaScript function finishes and releases the main thread.

There is only one main thread. JavaScript and the browser share it. When your code is running, the browser cannot repaint. When your code finishes, the browser runs its layout, paint, and composite steps and the screen updates.

This means if you make ten changes to the DOM inside one function, the user sees the result of all ten changes at once when the function returns, not one change at a time. This is actually good for performance. Batching changes inside a single execution avoids ten separate repaints.

It also means something counterintuitive: if you remove an element from the DOM and then immediately query the DOM to check if it is there, it will already be gone from the in-memory tree. But the user will still see it on screen until the function returns. The memory structure and the rendered page are not the same thing.

The Virtual DOM in Perspective

React introduced the virtual DOM as a way to batch and minimize actual DOM changes. A virtual DOM is just a JavaScript object that mirrors the structure of the real DOM but lives entirely in managed memory, separate from the browser's own tree.

When state changes in React, the virtual DOM is updated first. React then diffs the new virtual DOM against the previous one and computes the minimal set of real DOM changes needed. It applies only those changes.

This is a useful optimization. But it is worth knowing that vanilla JavaScript already has some of this behavior for free. If you change the same property ten times in one function, the browser only sees the final value when the thread releases. The actual repaint cost is similar whether the update went through a virtual DOM or not.

The virtual DOM adds value when the update pattern is complex and React's diffing algorithm is more efficient than what you would write by hand. It is not magic. It is a design choice, layered on the same real DOM that you can access directly.