CSE 134B

Step 09

Beyond the raw DOM

Eight steps of raw DOM invite an obvious question: why does almost nobody write applications this way? The answer is worth getting exactly right, because the popular versions of it are wrong in both directions — the DOM is neither too hard to use directly nor made faster by wrapping it. This closing step is the honest accounting: what the libraries over the DOM actually solved, what they solve now, and how to decide when you genuinely need one.

Learning Objectives

  • Translate between jQuery idioms and their modern DOM equivalents
  • Explain why the raw DOM is the performance floor, and what a virtual DOM actually is
  • Distinguish developer experience (DX) from user experience (UX) in framework claims
  • State a defensible rule for when to adopt a library

jQuery: the library that won so hard it disappeared

In 2006 the DOM you have been learning did not reliably exist. Browsers disagreed on event binding, on selection, on almost everything, and DOM code meant writing each operation two or three ways. jQuery wrapped the mess in one terse, chainable API — $('.fancy').on('click', fn) — and became the most successful JavaScript library ever shipped. Its ideas were so good the platform absorbed them: querySelector is jQuery's CSS-selector selection, standardized. Which is why the demo below is a jQuery comparison that loads no jQuery at all — every action is the vanilla equivalent of the jQuery one-liner shown beside it, at nearly the same length:

// jQuery: $("#sandbox").append("<div>Content added!</div>") sandbox.insertAdjacentHTML('beforeend', '<div>Content added!</div>'); // jQuery: $("#sandbox div").css("color", "red") sandbox.querySelectorAll('div').forEach(el => { el.style.color = 'red'; });

jQuery still runs a staggering share of the deployed web, and there is no shame in reading or maintaining it. But its reason for existing — papering over browser disagreement — is gone. Browsers converged; the holes it plugged are plugged by the platform.

The performance floor

Every framework — React, Vue, Svelte, all of them — eventually updates the page by calling the same methods you have spent eight steps learning. There is no other door into the renderer. It follows that an abstraction over the DOM cannot be faster than the DOM: used properly, the raw API is the performance floor, and every layer above it adds bytes to download, parse, and execute.

So what is a “virtual DOM”? A diffing strategy, not a faster tree. The framework keeps a model of the tree in memory, lets your components update the model freely, computes the difference from last time, and applies the difference to the real DOM in one batch. If your own code would have thrashed layout — dozens of components each poking the tree, interleaving the reads and writes step 8 warned about, inside a 16.7ms frame budget — the batching can rescue you. That is real, and it is also not speed. It is protection from a mess, purchased with overhead.

The claim, precisely. A virtual DOM cannot beat well-written direct manipulation; it can beat poorly orchestrated direct manipulation. What frameworks reliably deliver is not a faster page but a harder-to-degrade one — plus declarative views, state-to-UI consistency, and shared conventions a large team can hold onto. That is developer experience: real value, honestly priced. Notice which experience the marketing tends to claim.

So — framework or not?

Beware of solving problems you do not have. Coordinating thousands of components across a fifty-person team is a real problem — Facebook has it; your four-page course portfolio does not, and a framework there buys complexity, worse startup, and too often the accessibility failures of developers who skipped the markup underneath. Meanwhile ecosystem, hiring, and existing code are legitimately good reasons to adopt one, and none of them are performance.

So the rule this course teaches: use a library once you understand it, understand the problems it solves, and actually have those problems. You will use frameworks in your career — that is close to certain, and it is fine. Learning the platform first is not an argument against them. It is what makes you good at them: able to tell what the abstraction is doing, able to fix it when it leaks, and able to notice when it is not needed at all.

Next Steps

The whole series has been one move, practiced until it is reflex: select the nodes of interest, manipulate them, and repeat, until the page is in its new state. Everything from getElementById to IntersectionObserver was a refinement of that move — and every framework you meet from here on is someone else's opinion about how to organize it.

  • If you arrived here directly, the Events series is this series' other half — nothing above runs without it
  • The natural next series is Web Components, where disciplined DOM plus custom events become the platform's own component model — the framework ideas, standardized