What Is the DOM?

The Document Object Model is the browser's in-memory representation of a web page. When the browser parses the HTML, it builds a tree of objects, and that tree is the DOM. JavaScript does not see the markup itself, it sees this tree, and every change you make is a change to the tree.

The tree contains several kinds of node, and they are told apart by a numeric type. Element nodes are the tags themselves and carry the node type one. Text nodes are the character content between tags and carry the type three. Attribute nodes hold the values of an element's attributes. Comment nodes carry the type eight. And the document node is the root of the whole tree, with the element node for the html tag directly below it.

// A tiny stand-in for the browser DOM, so this example runs in Node.
const element = (tag, attrs = {}) => ({
  nodeType: 1,
  tagName: tag.toUpperCase(),
  attributes: attrs,
  childNodes: [],
  parentNode: null,
  appendChild(child) {
    child.parentNode = this;
    this.childNodes.push(child);
    return child;
  },
});

const textNode = (value) => ({ nodeType: 3, nodeValue: value, parentNode: null });

const list = element("ul", { id: "topics" });
const item = element("li");
item.appendChild(textNode("Closures"));
list.appendChild(item);

console.log(list.tagName);                               // "UL"
console.log(list.attributes.id);                         // "topics"
console.log(list.childNodes.length);                     // 1
console.log(list.childNodes[0].tagName);                 // "LI"
console.log(list.childNodes[0].childNodes[0].nodeValue); // "Closures"
console.log(list.childNodes[0].parentNode === list);      // true

Two distinctions matter in practice. The childNodes collection includes every kind of child, so text nodes are in there as well as elements, while the children collection contains only elements. A parent always has a reference back to its parentNode, which is what makes walking upwards possible.

The DOM is not the same as the HTML source. The browser corrects malformed markup, adds implied elements such as the body tag, and the tree you get is not always the tree you wrote. The DOM is also live: change it and the browser repaints the page, so it is a model of what is on screen rather than a document.

You walk the tree, either recursively or with an explicit stack, and you visit every node you care about. The expensive part is not the traversal itself but the fact that reading certain properties forces the browser to recompute the layout.

// A tiny stand-in for the browser DOM.
const element = (tag) => ({
  tagName: tag.toUpperCase(),
  children: [],
  parentNode: null,
  appendChild(child) { child.parentNode = this; this.children.push(child); return child; },
});

const build = (depth, width) => {
  const root = element("div");
  const grow = (node, level) => {
    if (level === 0) return;
    for (let i = 0; i < width; i++) {
      const child = element("span");
      child.textContent = &#96;level ${level} item ${i}&#96;;
      node.appendChild(child);
      grow(child, level - 1);
    }
  };
  grow(root, depth);
  return root;
};

const root = build(3, 3);

const walk = (node) => {
  let count = 1;
  for (const child of node.children) count += walk(child);
  return count;
};

console.log("nodes visited:", walk(root));   // 40

// The same work with an explicit stack, which never grows the call stack.
const countWithStack = (node) => {
  const stack = [node];
  let count = 0;
  while (stack.length) {
    const current = stack.pop();
    count += 1;
    for (const child of current.children) stack.push(child);
  }
  return count;
};

console.log("nodes counted:", countWithStack(root));   // 40

The recursive version is the one you will write most often, because it reads cleanly. The stack version matters for very deep trees, where recursion could exhaust the call stack, and for trees where you want to stop early, because a stack loop can break out of the loop without unwinding the recursion.

In a real browser the cost model is different. Walking the tree with the children collection is cheap, but reading a layout property such as offsetHeight, scrollTop or getBoundingClientRect forces the browser to flush any pending style changes and recalculate the layout, and then painting has to happen again. Doing that inside a loop over a thousand elements means a thousand layouts.

The fix is to separate the reads from the writes. Collect all the measurements you need first, then apply all the changes. That is the layout thrashing problem, and it is the subject of its own question.

You create it with createElement, then configure it and insert it into the tree. The order matters: set the content and the attributes before you attach the element, because attaching it puts it on screen and every change after that is a live update.

// The DOM only exists in a browser, so check before using it.
if (typeof document !== "undefined") {
  const link = document.createElement("a");
  link.textContent = "Docs";
  link.href = "/docs";
  link.className = "nav-link";
  link.setAttribute("data-id", "42");

  document.body.appendChild(link);

  console.log(link.tagName);                 // "A"
  console.log(link.getAttribute("data-id")); // "42"
  console.log(document.querySelectorAll("a").length);   // 1
} else {
  console.log("No DOM in this runtime - open a browser console to try it.");
}

There are two ways to set most attributes and the difference is worth knowing. The property form, like link.href or link.className, sets the underlying property, which is what the element actually uses, and it is usually the right choice for things like value, checked and disabled where the property and the attribute can disagree. The setAttribute method sets the attribute in the markup, which is what you want for data attributes and for anything the user will see in the inspector.

For styles, the style property gives you direct access to individual CSS declarations, while the cssText property replaces the whole declaration block at once.

One more detail to have ready. Setting innerHTML with a string that came from a user is a cross-site scripting risk, because the browser parses it as markup. Text content is always safe, and for anything untrusted you want textContent rather than innerHTML.