前置知识

相关文章

工具 · 1,315 字 · 6 分钟阅读

The DOM: Making Web Pages Programmable

The W3C's Document Object Model turned static HTML into a living tree that JavaScript could read, modify, and rebuild — the API that made the interactive web possible.

目录
  1. TL;DR
  2. Before the DOM: Two Browsers, Two Worlds
  3. The W3C Steps In
  4. The Tree
  5. Creating and Destroying
  6. Events: The Nervous System
  7. The Performance Problem
  8. DOM Levels and Evolution
  9. What the DOM Got Right

#TL;DR

JavaScript gave the browser a programming language. But a language needs something to manipulate. The Document Object Model — standardized by the W3C in 1998 — gave JavaScript a structured representation of every element on the page: a tree of nodes that could be traversed, read, modified, and rebuilt in real time. Before the DOM, each browser had its own incompatible way of accessing page elements. Netscape had document.layers. IE had document.all. Code written for one broke in the other. The DOM replaced this chaos with a single, language-neutral API that turned HTML from a static document into a live data structure. Every interactive web feature — dropdown menus, form validation, infinite scrolling, single-page applications — is built on the DOM. Every frontend framework from jQuery to React is, at its core, a more convenient way to manipulate it.

#Before the DOM: Two Browsers, Two Worlds

In the late 1990s, both Netscape Navigator and Internet Explorer had JavaScript. Both could change things on a page. But they exposed the page through completely different APIs.

Netscape 4 used document.layers — a proprietary system where positioned elements were accessed by name through a layers collection:

// Netscape 4: show a dropdown menu
document.layers["dropdown"].visibility = "show";
document.layers["dropdown"].top = 100;

Internet Explorer 4 used document.all — a flat collection of every element on the page, accessed by ID:

// IE 4: show a dropdown menu
document.all["dropdown"].style.visibility = "visible";
document.all["dropdown"].style.top = "100px";

Same goal. Incompatible code. Developers had to write everything twice, wrapped in browser detection:

// The reality of 1997 web development
function showMenu() {
  if (document.layers) {
    document.layers["menu"].visibility = "show";
  } else if (document.all) {
    document.all["menu"].style.visibility = "visible";
  }
}

This wasn’t an edge case — it was every piece of dynamic behavior on every website. The browser wars weren’t just about market share. They were fragmenting the web into two incompatible platforms.

#The W3C Steps In

The World Wide Web Consortium — founded by Tim Berners-Lee in 1994 to maintain web standards — took on the problem. If browsers were going to expose page structure to scripts, there needed to be a single, standard way to do it.

The DOM Level 1 specification was published in October 1998. It defined two things:

  1. A tree model — every HTML document is represented as a tree of nodes, where every element, attribute, and piece of text is a node with parent-child relationships
  2. A standard API — a set of methods and properties for navigating, reading, and modifying that tree

The key insight: the DOM isn’t the HTML. HTML is a text format — angle brackets and attributes. The DOM is the parsed, in-memory representation of that HTML as a live data structure. The browser reads the HTML, builds the DOM tree, and everything you see on screen is rendered from the tree, not from the original text.

HTML source:                    DOM tree:

<html>                          Document
  <body>                         └── html
    <h1>Hello</h1>                   └── body
    <p>World</p>                          ├── h1
  </body>                                │    └── "Hello"
</html>                                  └── p
                                              └── "World"

#The Tree

Every element in an HTML document becomes a node in the DOM tree. The relationships are what you’d expect: <body> is the parent of <h1>, <h1> is a child of <body>, and <h1> and <p> are siblings.

// Navigating the tree
const body = document.body;
const firstChild = body.firstElementChild;      // <h1>
const nextSibling = firstChild.nextElementSibling; // <p>
const parent = firstChild.parentElement;         // <body>

// Every node knows its position in the tree
console.log(firstChild.tagName);     // "H1"
console.log(firstChild.textContent); // "Hello"

There are several types of nodes — element nodes (<div>, <p>), text nodes (the actual characters), comment nodes (<!-- ... -->), and the document node itself. But in practice, developers work almost exclusively with element nodes through a small set of core methods:

// Finding elements
document.getElementById("main");              // by ID (fastest)
document.querySelector(".card:first-child");   // by CSS selector
document.querySelectorAll("article p");        // all matches

// Reading and modifying
const el = document.querySelector("h1");
el.textContent = "New title";            // change text
el.setAttribute("class", "highlight");   // change attribute
el.style.color = "blue";                // change inline style
el.classList.add("active");              // toggle a CSS class

#Creating and Destroying

The DOM isn’t read-only. JavaScript can build new elements from scratch, insert them into the tree, and remove existing ones. The page updates in real time — no reload needed.

// Create an element, configure it, add it to the page
const card = document.createElement("div");
card.className = "card";
card.innerHTML = `
  <h2>New Post</h2>
  <p>This element didn't exist in the original HTML.</p>
`;
document.querySelector("#feed").appendChild(card);

// Remove an element
const old = document.querySelector(".outdated");
old.remove();

This is the mechanism behind every dynamic web feature. An infinite-scrolling feed creates new elements and appends them as you scroll. A single-page application removes the current page’s DOM and replaces it with new content fetched via AJAX. A form validation script adds error message elements next to invalid fields.

The DOM is the surface that makes the static web dynamic.

#Events: The Nervous System

The DOM doesn’t just represent structure — it’s an event system. Every user interaction generates events that bubble through the tree, and JavaScript can listen for them at any node:

// Listen for a click on a specific button
document.querySelector("#submit").addEventListener("click", function(event) {
  event.preventDefault();  // stop the form from submitting normally
  validateAndSubmit();
});

// Event delegation: listen on a parent, handle events from children
document.querySelector("#todo-list").addEventListener("click", function(event) {
  if (event.target.matches(".delete-btn")) {
    event.target.closest("li").remove();
  }
});

Events bubble — a click on a <button> inside a <form> inside <body> fires the click handler on the button, then the form, then the body, then the document. This is why event delegation works: you can listen on a parent element and handle events from any of its descendants, even ones that don’t exist yet.

Click on <button>
  ↓ capture phase (down the tree)
  document → body → form → button
  ↑ bubble phase (up the tree)
  button → form → body → document

The event model is what connects JavaScript to the user. Every keystroke, mouse movement, scroll, focus change, and touch gesture generates DOM events. Without events, JavaScript is a language with nothing to react to.

#The Performance Problem

The DOM has a cost. It’s a live data structure, shared between the JavaScript engine and the rendering engine. Every time you modify it, the browser may need to recalculate styles, recompute layouts, and repaint pixels on screen.

// Bad: triggers layout recalculation on every iteration
const list = document.querySelector("#list");
for (let i = 0; i < 1000; i++) {
  const li = document.createElement("li");
  li.textContent = `Item ${i}`;
  list.appendChild(li);  // browser may re-layout each time
}

// Better: build off-screen, insert once
const fragment = document.createDocumentFragment();
for (let i = 0; i < 1000; i++) {
  const li = document.createElement("li");
  li.textContent = `Item ${i}`;
  fragment.appendChild(li);  // no layout cost — fragment is off-screen
}
list.appendChild(fragment);  // one insert, one layout

Reading layout properties (offsetHeight, getBoundingClientRect()) forces the browser to synchronously compute the layout — a phenomenon called forced reflow. Interleaving reads and writes in a loop is the classic DOM performance mistake:

// Terrible: read-write-read-write forces layout thrashing
items.forEach(item => {
  const height = item.offsetHeight;  // forces layout
  item.style.height = height + 10 + "px";  // invalidates layout
  // next iteration forces layout again...
});

This overhead is why frameworks exist. jQuery (2006) smoothed over browser differences and made the API more pleasant. React (2013) introduced the virtual DOM — a lightweight JavaScript copy of the DOM tree. React computes changes on the virtual copy (cheap), diffs it against the real DOM (cheap), then applies only the minimal set of actual DOM mutations (expensive but minimized). Svelte (2016) went further, compiling away the virtual DOM entirely and generating surgical DOM updates at build time.

Every frontend framework is, at its core, a strategy for making DOM manipulation efficient. The DOM is the bottleneck they’re all optimizing around.

#DOM Levels and Evolution

The DOM evolved through several W3C specifications:

DOM Level 1 (1998) — the core tree model and basic element access. getElementById, createElement, appendChild. The foundation.

DOM Level 2 (2000) — events (addEventListener), style access (element.style), and traversal. This is when the DOM became interactive.

DOM Level 3 (2004) — keyboard events, document loading, XPath support.

The Living Standard (2015–present) — the WHATWG took over DOM standardization from the W3C, maintaining a continuously updated spec rather than numbered versions. Modern additions include querySelector/querySelectorAll, classList, closest(), MutationObserver, and the Shadow DOM for encapsulated components.

The trend has been steady: each generation adds convenience methods that reduce the need for libraries. Modern vanilla JavaScript can do what jQuery did in 2006 without any dependencies — querySelector replaced Sizzle, classList replaced class manipulation hacks, fetch replaced $.ajax.

#What the DOM Got Right

The DOM was a compromise — designed by committee, verbose by nature, slow under pressure. And it became the most important API in the history of user interfaces:

  • Language neutrality — the DOM is defined independent of any programming language. JavaScript is its primary consumer, but the same API specification applies to Python, Java, and any language with a DOM implementation. This made the spec portable and prevented lock-in to any single language or browser vendor.
  • The tree abstraction — representing a document as a tree of nodes was the right structural choice. Trees are well-understood, efficiently traversable, and map naturally to both HTML’s nesting structure and visual rendering. Every UI framework that followed — native or web — uses some form of tree-based component model.
  • Events as architecture — the DOM’s event system didn’t just handle clicks. It established a pattern — event-driven, loosely coupled, declarative — that became the dominant paradigm for user interface programming. React’s onClick, Vue’s v-on, Svelte’s on:click — they’re all abstractions over DOM events.
  • The universal render target — because every browser implements the same DOM API, every web application has the same render target. This is why “write once, run anywhere” actually works on the web when it never quite worked for Java. The DOM is the stable contract between application code and the browser’s rendering engine.

The DOM made HTML a programmable data structure. That single change — from a document you read to a tree you manipulate — is what turned the web from a publishing medium into an application platform. Every dropdown menu, every drag-and-drop interface, every single-page application, every real-time dashboard is built by JavaScript talking to the DOM. It’s the API beneath everything.