Frontend, what users see

That layer is the frontend, everything users see and touch: the buttons, the text, the layout, the animation confirming a tap landed.

In the journey of a request, this layer was the client, the part that turns taps into requests and responses into pixels. This chapter teaches you to read a few real lines of it, the elements AI products added, and how to describe a screen so a tool can build it.

HTML, CSS, and JavaScript, the materials of every screen

Every page a browser shows mixes the same three materials, and the fastest way to meet them is to read that Save button at toy scale. First, its HTML:

<button class="save-btn">Save</button>

The tag button says what this is, so the browser draws something tappable; the word Save between the tags is the label the user reads; and class="save-btn" is a handle the other two materials use to find it. HTML answers one question: what exists on the page.

Next, the CSS rule that dresses it:

.save-btn {
  background: #16a34a;
  border-radius: 8px;
}

The first line points at anything carrying the save-btn handle, the background line paints it green, and border-radius rounds the corners. #16a34a is a hex code, a color written as a number so a tool or a designer can pin down one exact green. CSS answers the second question: how things look.

Last, the JavaScript click handler, the lines that run when the tap lands:

button.addEventListener("click", () => {
  button.textContent = "Saved";
  fetch("/save", { method: "POST" });
});

The first line runs what follows whenever the button is clicked, the second flips the label to Saved, and the third, the fetch line, sends the request that records the save. Reread the order: the label changes before the server hears anything, and nothing here flips it back if the request fails. Those three lines are the demo mystery, and the reason Instagram's heart turns red before your like reaches any server: the flip runs on the phone, ahead of the request.

Every screen mixes the same three materials: HTML is the structure, what exists; CSS is the appearance, how it looks; JavaScript is the behavior, what happens when the user acts. Together they are the triad.

You will not write the materials by hand. Your tools write them constantly and narrate as they go, and the triad makes that narration readable: .html edits change what exists, .css edits change how things look, and click-handler edits change what the page does. Modern tools mostly work in components, reusable chunks of screen carrying structure and behavior in one file, but the jobs inside stay distinct.

The obvious objection: your tools write all three

If the tools write all three materials, telling them apart can look like trivia. It stops looking that way at your first diff, the list of proposed edits a tool asks you to approve: a change can touch a dozen files, and the triad turns that wall of code into moves you can sort by job, so a change you cannot sort is a change you accept rather than steer. Sorting also catches a line in the wrong layer: the Save button said Saved early because one behavior line ran ahead of another, and an API key, the password your product uses with a paid service, pasted into frontend code is a secret in the one layer every user can read.

What AI products add to the screen

The classic frontend vocabulary settled long ago: buttons, forms, menus, lists, cards. AI products kept all of it and added new elements, because a generated answer behaves unlike anything they were built to hold: it arrives over seconds rather than milliseconds, rests on sources, is sometimes wrong, and sometimes comes right before an action the product takes for you.

• The streaming block. A text area that fills word by word while the response is generated, so reading starts before the work finishes.
• The citation chip. A small numbered marker attached to a sentence, tying the claim to its source.
• The source rail. The list of sources alongside the answer, one entry per chip, so a reader can check the original.
• Approve and undo controls. When the product is about to act (send the email, apply the edit, delete the rows), the screen asks first or offers a way back, so the human stays in charge.
• The working state. What the screen shows while the model runs: step labels and progress notes that make a multi-second wait feel honest instead of frozen.

One real screen carries most of this vocabulary. Ask Perplexity a question and the answer streams into the block, numbered citation chips sit at the ends of sentences, and the sources are listed alongside, one per number, so the screen shows which sentences rest on which sources.

Describe a screen so a tool can build it

Sometimes a tool asks what a screen should look like; more often it picks a layout and starts building, and your job is to notice and steer. A buildable description needs no pixel art, no measurements, no hex codes: it says what the user sees, in what order, and what each element does, starting with who is on the screen and what they came to do.

Two kinds of question keep coming back from your tool. What should this look like is a UI question (user interface, the look a screenshot captures); what should the user do first is a UX question (user experience, what using the product feels like over time).

Our family nutrition app FuelTheFam turns a photo of an open fridge into a shopping list, and its list screen is described for the tool this way: A parent has just photographed their fridge and is waiting. From the top: a thumbnail of their photo, then a streaming block where the list arrives item by item, a notice with a retake button if the photo was too dark to read, and a save button that asks before it saves. The first draft it produced was wrong in ways we could only see once it existed; yours will be too, and your reaction makes the second pass closer, the loop that Wire the model into your build turns into a method.

Try it now

This drill takes about fifteen minutes; the no-setup path spends nothing, the tooled path a few cents at most. You leave with one screen sorted into the triad in a few written lines.

No setup: On a laptop or desktop (phone browsers do not offer this), right-click anything on any page and choose Inspect; Safari keeps the panel off until you enable its web developer features in Settings, so the quickest route is Chrome or Firefox. The panel is DevTools, the one from the opening scene: the HTML skeleton on one side, the CSS dressing your selected element on the other. Find a color value in the Styles panel and change it; the page updates instantly, and on reload it snaps back, because you edited your browser's local copy, never the real site. Then open an AI product you use and write three lines sorting its answer screen into the triad: what exists, how it looks, what reacts.

With your tools: In an empty folder, ask Claude Code for a one-page site about anything, then describe one change the way this chapter taught: "move the heading above the image and turn the contact line into a button." Before approving, read which files it plans to touch and sort them with the triad: what exists lands in HTML or component files, how it looks lands in CSS, and what it does lands in handlers. The diff stops being a wall of code and becomes a sorting exercise. If nothing is installed yet, the Setup Clinic gets you running. Same move in Codex or Cursor: describe the change in the sidebar and sort the touched files before accepting.

Chapter Summary

• The frontend is everything users see and touch, and it runs on the user's own device, which is why a screen can answer before the server has heard anything.
• Every screen mixes three materials: HTML declares what exists, CSS declares how things look, and JavaScript declares what happens when the user acts. Together they are the triad.
• You will not write the materials by hand, but your tools narrate their work in them, so sorting a diff with the triad turns a wall of code into moves you can read and steer.
• Only a reader catches a line in the wrong layer: a label that flips before its request is sent, or a secret pasted into code every user can read.
• AI products kept the classic parts and added their own: the streaming block, the citation chip, the source rail, approve and undo controls, and the working state.
• To get a screen built, describe what the user sees, in what order, and what each element does, starting with who is on the screen and what they came to do.
• What a screen should look like is a UI question; what the user should do first is a UX question; answer them separately and both answers improve.
• The first draft will be wrong in ways you can only see once it exists, and your reaction makes the next pass closer.
• Secrets and rules about money or data cannot live in frontend code, because every user can read it. Next, Backend, where the real work happens shows where they live instead.

Sources

• MDN Web Docs, the HTML, CSS, and JavaScript references (last verified July 2026).
• Chrome DevTools documentation, and Apple's Safari documentation on enabling web developer features (last verified July 2026).
• Perplexity (perplexity.ai): the streaming answer, numbered citation chips, and source list describe its live product behavior (last verified July 2026).
• Instagram: the heart fills immediately on tap, observable in the app (last verified July 2026).
• FuelTheFam (fuelthefam.com), our family nutrition app; the fridge list screen description is from our build.