What the browser does and what the server does

Your API returns twelve bytes of JSON. Somewhere between those bytes and the person holding the phone there is a screen with text, buttons and colours on it. Frontend is the name of that last stretch of the journey, and it is the part that runs on a machine you do not own.

You already know the two roles from the architecture lessons. The server holds the data, decides who may read it, and answers with JSON. The browser asks and then draws. This lesson is about the word then: what actually happens inside the browser after the answer arrives, and why that part deserves its own set of ideas.

The browser keeps the page as a tree of elements, called the DOM. Every tag becomes a node, and nesting becomes a parent-child link. If you have met trees in logic, this is the same idea: one root, branches, and leaves that hold the text. When you write a tag, you are describing a shape of that tree.

document
  html
    head
      title
    body
      h1
      ul
        li
        li
        liThe page as a tree: one root, branches, and text at the leaves.

The oldest way to update the page is to walk that tree yourself. Find the node, create a new element, attach it, set some text. It works, and for a page with one interactive detail it is still the right answer.

const list = document.querySelector("#cart-items");

const row = document.createElement("li");
row.textContent = "Tea";
list.appendChild(row);

document.querySelector("#total").textContent = "12.90";Hand-written updates: create the element, attach it, set the text, remember the total.

A framework changes the question. Instead of instructions for the browser, you write a description of what the screen should look like for the data you have. Here is that same basket, described rather than commanded.

const cart = ["Bread", "Tea", "Apples"];

function Cart({ items }) {
  return (
    <ul>
      {items.map((item) => (
        <li>{item}</li>
      ))}
    </ul>
  );
}

const view = <Cart items={cart} />;

Be honest about the trade. A framework is more code, a build step, another thing to learn, and a real cost in the size of what you ship to the phone. What you buy with it is a rule that holds as the page grows: the screen is described from the data, once, in one place. Every framework argument you will ever have is really an argument about whether that trade is worth it for this project.