Browsers begin life as parsers

Open a new tab and nothing really happens—until something arrives. What arrives is always a string of bytes. Give browsers this string and they turn it into something else: a tree of nodes. If you’ve ever written a compiler this is familiar: <h1> is a token,<div> is another and so on. Tokens carry meaning (e.g.</h1> closes a branch). The rules live in the HTML spec^[1]; the result is the DOM.

The global document object is your entry point into the DOM^[2]. It represents the entire page and exposes methods likequerySelector and createElement to inspect and modify the DOM. After the DOM is built you can poke that tree with JavaScript: call document.createElement to grow a new branch, appendChild to graft it on orremove() to amputate. It feels powerful—until you have to remember every incision you made five minutes ago.

We manipulate the DOM to bring pages to life. Scripts update text or styles when data changes, respond to clicks, keyboard input or other events, show and hide elements, and generally make the UI interactive. The DOM API allows your code to change a document’s structure, style or content and attach event handlers so user actions trigger logic^[3]. Without such mutations, a web page would remain static and unresponsive.

Leave out that last line just once—say, inside an error path—and the UI shows “3” while count is actually 4. Side‑effects accumulate and state (the remembered values your program uses to compute results) drifts^[4], and eventually a user wonders why the “Save” button stops working after the tenth click. Imperative code demands you remember every prior mutation; the browser will not remind you.

In the late 1990s a “heavy” web page had maybe fifty nodes—some <table> rows, a handful of images, and a sprinkling of <font> tags. A single innerHTML swap was cheap because there was almost nothing to recalculate.

Fast‑forward to 2007 and Gmail, Google Maps and Facebook were running in the tab next to your email. They streamed new data every few seconds, animated sidebars, and ran rich text editors in place. Suddenly one page could host thousands of DOM nodes, each with styles, transitions and event listeners. Anything that forced the browser to re‑measure positions had to walk a tree the size of a small novel.

The hardware curve didn’t bail us out: laptops of the day shipped with 1 GB of RAM and phone CPUs barely touched 500 MHz. Developers learned a painful truth: cost scales with surface area. Twice the nodes means twice the style rules to match and twice the layout boxes to compute—multiplied by 60 frames per second if you’re animating.

Worse, the cost is incremental. Each call to textContent or style.width =  doesn’t just tweak a property; it invalidates caches, dirties style data and queues a layout pass. Do that inside a loop or inside a scroll handler and you get jank: the UI stutters because the main thread is busy re‑flowing pixels you can’t even see.

So when people say “the DOM is slow” they don’t mean the API is sluggish—they mean naïve mutation patterns amplify hidden work. The larger and more interactive the page, the higher the hidden bill.

Updating a DOM node looks like a single operation, but under the hood it punches a five‑stage pipeline: JavaScript runs, styles recalibrate, layout recalculates where every pixel goes, paint splashes color into new bitmaps, and the compositor finally stitches layers together. One stray textContent change can ripple all the way to GPU memory^[5].

Fig 1 – the render pipeline every mutation can trigger.

The bill arrives per mutation. Add 1 000 list items the naïve way and you pay for 1 000 layouts:

1// ❌ 1 000 reflows – one per iteration
2for (let i = 0; i < 1000; i++) {
3  const li = document.createElement("li");
4  li.textContent = `Item ${i}`;
5  document.body.appendChild(li);      // layout + paint each time
6}

Listing F – one layout per appendChild → jank.

Batch first, mutate once, and the cost collapses:

Reads can hurt too. Ask for offsetWidth right after you tweak styles and the engine must flush layout synchronously—a pattern called layout thrashing.

Fig 2 – mutate → forced read → mutate … each jump flushes the pipeline.

Props & state

React components juggle two data sources. Propsflow into a component from its parent and are immutable.State lives inside a component and can change – triggering a new render. Everything visible on screen is a pure function of(props, state).

Fig 9 – props cascade downward; only callbacks travel up.

A canonical pattern: parent owns state, passes value + callback to a child. The child never mutates data directly; it requests changes by calling the callback.

The button displays value (a prop) yet changes it by invoking onIncrement. The update travels up, setStatefires, React re‑renders Parent, and the new prop cascades back down.

Fig 10 – one click’s round‑trip through the data flow.

Local state is for information the component alone owns – e.g. UI toggles, transient form input:

A golden rule: never mutate props. Doing so violates the parent’s expectations and destroys the guarantee that render is pure.

1// ⚠️ anti‑pattern: child mutates prop object
2function List({ items }) {
3  items.push("⚠️");          // bad – breaks parent's assumptions
4  return <ul>{items.map(i => <li key={i}>{i}</li>)}</ul>;
5}

Listing O – anti‑pattern: mutating a prop breaks referential integrity and can cause phantom re‑renders.

In practice, most state lives at the lowest shared ancestor that needs the data – a principle nicknamed “lift state up.” React’s one‑way data flow keeps mental overhead low: to understand any component, trace props in, local state inside, and callbacks out. No hidden observers, no two‑way bindings.

Lifecycle

Every component lives three main moments: mount (birth),update (growth), and unmount (death). React’s mission is to make these transitions predictable and side‑effect free.

Fig 11 – the life‑cycle in three acts.

Class lifecycles (legacy)

Class components expose explicit callbacks like componentDidMountand componentWillUnmount. They still work, but hooks ± function components are simpler:

Functional lifecycles (hooks)

useEffect merges didMount + didUpdate +willUnmount into one API:

The effect runs after commit, and its return value handles cleanup. Supply a dependency array to control when updates fire. An empty array [] means “mount once.”

Layout vs passive effects

React splits effects into two buckets: useLayoutEffect runssynchronously after DOM mutations but before the browser paints (good for measuring layout). useEffect waits untilafter paint, keeping the main thread free for user input.

Fig 12 – order of operations inside the commit phase.

Rules of thumb

• Read / measure in useLayoutEffect;fetch / subscribe in useEffect.
• Always declare dependencies; React’s lint‑rule helps you stay honest.
• Cleanup everything you created: event listeners, timers, observers.