How Do You Change the Page with JS?

There are three main levers, and choosing the right one is most of the skill. The textContent property sets the text inside an element and always treats the value as plain text. The innerHTML property takes a string of markup and parses it. The classList property adds and removes class names, which is how you change appearance without touching styles directly.

// The DOM only exists in a browser, so check before using it.
if (typeof document !== "undefined") {
  const card = document.querySelector(".card");

  // Plain text - always safe.
  card.textContent = "Welcome back";

  // Markup - parsed as HTML.
  card.innerHTML = "<strong>Welcome back</strong>";

  // Classes drive the styling.
  card.classList.add("is-active");
  card.classList.remove("is-loading");
  console.log(card.classList.contains("is-active"));   // true

  // Attributes for everything else.
  card.setAttribute("aria-live", "polite");
} else {
  console.log("No DOM in this runtime - open a browser console to try it.");
}

The security rule is the one to remember. Setting innerHTML with a string that contains user input lets the browser parse it as markup, so a value containing a script tag becomes a cross-site scripting hole. Setting textContent never has that problem, because the value can only ever be text. If you need markup from an untrusted source, sanitise it first.

There is a performance difference too. Assigning to innerHTML parses a whole new subtree and throws away the old one, which means any event listeners on the old children are lost and any references you held are stale. Setting textContent on a leaf node does not have that cost.

For styling, the style property gives you access to individual declarations and the cssText property replaces the entire declaration block. The classList property is usually better than either, because it keeps the decision about what something looks like in the stylesheet where it belongs.

Both give you the text of an element, but they differ in how they treat the markup inside it and what they do with hidden content.

TextContent returns the raw text content of the element and all its descendants, exactly as it appears in the source. It ignores the structure entirely, so markup tags are not included, and it includes text that is inside hidden elements, which is why it is faster and cheaper to compute.

InnerText is the rendered text. It approximates what the user actually sees, which means it skips content that is hidden with the display property, respects line breaks inserted by the layout, and applies whitespace normalisation so that multiple spaces collapse into one. It also brings extra line breaks around block level elements.

That difference is why the two give different results for the same element, and it matters when you are reading user-visible text. If you are copying what the user sees, use innerText. If you are extracting raw data, such as the contents of a script tag or a hidden field, use textContent.

The same distinction applies to the setter. Assigning to textContent replaces the content with plain text, while assigning to innerHTML parses the value as markup. There is no innerText assignment that parses markup, so the two setters are not symmetric with the two getters, which is a detail worth mentioning if you are asked to compare them carefully.

The rule is to separate reading from writing. Reading a layout property forces the browser to work out where everything is on the page, and writing a style invalidates that work. Interleaving the two in a loop means paying for both on every iteration.

// The DOM only exists in a browser, so check before using it.
if (typeof document !== "undefined") {
  const items = [...document.querySelectorAll(".item")];

  // Bad: read, write, read, write - the layout is recalculated each time.
  items.forEach((el) => {
    const height = el.offsetHeight;
    el.style.height = `${height + 10}px`;
  });

  // Better: do every read first, then every write.
  const heights = items.map((el) => el.offsetHeight);
  items.forEach((el, i) => {
    el.style.height = `${heights[i] + 10}px`;
  });

  // Build the new content off the page and attach it in one go.
  const fragment = document.createDocumentFragment();
  for (const label of ["One", "Two", "Three"]) {
    const li = document.createElement("li");
    li.textContent = label;
    fragment.appendChild(li);
  }
  document.querySelector("ul").appendChild(fragment);

  console.log("updates applied");
} else {
  console.log("No DOM in this runtime - open a browser console to try it.");
}

The fragment is the other half of the answer. A document fragment is an off-document container, so you can add hundreds of nodes to it and the browser does no layout work at all until you attach the fragment in a single operation. Appending the same nodes one at a time to the live document would trigger a layout for each one.

Two more techniques worth naming. Replacing the whole subtree with innerHTML is fast when the new markup is a big chunk of the page, because the browser parses it in one pass, though it destroys listeners on the old children. And if you are building a modern interface, a virtual DOM diffing approach handles this for you, which is one of the practical reasons a framework can feel faster than hand-written updates even though it does more work in JavaScript.