A web page = three jobs

Every page you've used — shop, dashboard, bank app — splits its work into these three files.

How a page gets to your screen

The frontend is the client side. The server's job ends the moment it hands over three kinds of files — everything after happens in your browser.

server ──(html · css · js)──▶ browser ──(pixels)──▶ your eyes

What happens when you open a URL

Four beats. After beat 3 the page is alive in your browser — and beat 4 repeats on every click.

1. 1

   You open a URL

   Your browser asks a server: 'give me this page'.

2. 2

   Server answers with files

   It sends HTML + CSS + JS. The whole answer is just text files.

3. 3

   Browser builds the page

   HTML becomes a tree of elements, CSS paints and places them, JS starts running.

4. 4

   You click — the loop repeats

   JS reacts on the spot; for new data it can ask the server again (an API call) — no reload.

The AI writes. You steer.

This deck is that map — recognize, judge, fix.

A whole page, 11 lines

Two halves: <head> is metadata and links (invisible), <body> is everything you can see.

<!doctype html>
<html>
  <head>                      ← invisible: title, CSS links
    <title>My page</title>
    <link rel="stylesheet" href="style.css">
  </head>
  <body>                      ← everything the user sees
    <h1>Hello, world</h1>
    <p>This is the first paragraph.</p>
    <p id="status"></p>
  </body>
</html>

Right side is the live render of this exact page — click the status line, it becomes editable. Tags come in pairs: <h1>…</h1>.

Three rules — that's the whole syntax

HTML has almost no syntax. Keep these three and you can read any page.

The tags you'll recognize everywhere

You don't need to memorize HTML — you need to recognize it when you (or your AI) read it.

A menu bar, in plain HTML

A logo, a list of links, a button. No CSS yet — just structure.

<nav>
  <a class="logo">MyShop</a>
  <ul>
    <li><a href="/shop">Shop</a></li>
    <li><a href="/about">About</a></li>
  </ul>
  <button>Log in</button>
</nav>

Right side is live — click Shop, About or Log in and the click is reported inline. Every menu bar you've seen is some version of this <nav>.

A typical page, as a tree

Almost every web app you've used has this exact shape: bar on top, rail on the left, content in the middle.

<body>
├── <nav>          menu bar — logo, links, 'login'
├── <div class="layout">
│   ├── <aside>    sidebar — filters, sub-menu
│   └── <main>     content — what the page is about
└── <footer>       links, copyright

# every element above is just a <div> or its friends —
# the layout you see is CSS placed on this tree

Read this tree top to bottom and you can name almost any admin dashboard's structure.

Common UI — what it's really made of

Recognize the pattern, don't master the syntax. Most 'fancy' UI is plain HTML wearing CSS.

A login form, 7 elements

The most common UI on the web: a field to type in, and a button to send it.

<form>
  <label>Email</label>
  <input type="email" placeholder="you@example.com">

  <label>Password</label>
  <input type="password">

  <button type="submit">Log in</button>
</form>

Right side is live — hit Log in and the form reports back (JS would intercept it here). Each <label> describes the <input> next to it.

id vs class — two ways to name an element

Semantic tags carry meaning, not just shape

<div> means nothing. <nav>, <main>, <article> say what a region IS.

A product card, in plain HTML

Every card on the web — product, profile, post — is this shape: image on top, title, text, action.

card.html

<div>
  <img src="product.jpg" alt="Espresso machine">
  <h3>Espresso Machine</h3>
  <p>Pulls a proper shot at home.</p>
  <button>Add to cart</button>
</div>

Live — try it

Espresso Machine

Pulls a proper shot at home.

Add to cart

Right side is the live card — click Add to cart. This exact markup becomes a Bootstrap card next, just by adding class names.

The HTML mistakes worth catching

The bugs AI (and humans) still ship. You don't have to find every one — just recognize these four.

Everything on a page is a box

Every element is a rectangle with four concentric rings. This one mental model explains most of CSS.

How CSS finds what to style

Every CSS rule = an address + a list of properties. Three address types cover 95% of CSS.

What 'style' actually means

A CSS rule = pick an element, then assign it properties. That is the entire syntax.

button {
  padding: 10px 18px;     /* room inside */
  background: #34d399;    /* colour */
  border: none;
  border-radius: 8px;     /* rounded corners */
  color: white;
  font-size: 15px;
}

Right side is live — that's the exact CSS from the box applied to the button. Hover it. AI writes this; knowing padding / border / radius is how you review it.

Three layout tools, one job

Layout = deciding where things sit. CSS has exactly three big tools for that.

Flexbox, drawn

display: flex puts items in a line. Two axes do all the work — every other flex property is just a knob on one of these.

justify-content moves items along the MAIN axis · align-items moves them along the CROSS axis

justify-content — spacing along the main axis

The boxes are real: each row is an actual flex container with that exact property. This is what the browser computes.

space-between: items hug the edges, gaps only between · space-around: equal room for every item, half at the edges

Wrap, grow, direction

Three more properties cover most real flex layouts. All three boxes below are live flex containers.

wrap: overflow starts a new row · grow: one item fills what's left · column: the line becomes a column

Grid — rows AND columns at once

Left: nine boxes in a 3×3. Right: boxes that span. Same idea, far less code than stacking flexboxes.

Bootstrap's col-3 is this same grid with 12 columns: col-3 = 3 of 12 = a quarter of the row

One codebase, two layouts

The media query is a switch: same elements, different arrangement per screen size.

/* desktop: sidebar next to content */
.layout { display: flex; }

/* phone: sidebar stacks on top */
@media (max-width: 768px) {
  .layout { flex-direction: column; }
}

Right side is a live window — drag the slider past 768px and the sidebar stacks. Below 768px the same page rearranges itself; that is 'responsive'.

Same button, two ways

That's the whole pitch: consistency for free, so you spend time on the page — not on pixels.

Same markup — the classes are the magic

Identical HTML, same photo. The right side only adds class names — and it suddenly looks designed.

plain html — no classes

Espresso Machine

Pulls a proper shot at home.

Add to cart

same markup + bootstrap classes

Espresso Machine

Pulls a proper shot at home.

Add to cart

card · card-img-top · card-body · card-title · card-text · btn btn-primary

The components you'll see everywhere

Everything below is real Bootstrap 5, rendered in this slide. Each piece is one or two class names.

Aero Chair

Ergonomic. Breathable. Actually comfortable.

View product

Order #4821 confirmed paid

3 items under $10 deal

Primary Outline Success Link

New Beta Live Down

navbar · card · alert · badge · btn — the vocabulary of a thousand dashboards

Forms stop looking default

The same inputs you saw in the HTML part — now with form-* classes. Focus states and spacing included.

form-label · form-control · form-select · form-check form-switch · btn

A page in 11 lines of classes

No <style> block at all — the page's whole look comes from the class names.

<link href="bootstrap.min.css" rel="stylesheet">

<nav class="navbar">…logo + links…</nav>

<div class="container">
  <div class="row">
    <div class="col-3">sidebar</div>
    <div class="col-9">main content</div>
  </div>
  <button class="btn btn-primary">Click me</button>
</div>

col-3 / col-9 is the grid: 12 columns, 3+9 fills the row. Change the numbers — the layout changes.

Classes worth recognizing

You won't memorize Bootstrap — but these six show up in almost every page built with it.

The 12-column grid, in one slide

Every Bootstrap layout is rows of 12 equal slots. You pick how many each block takes.

One listener, one update

The pattern behind every interaction on the web: listen for an event, then change the page.

const btn = document.querySelector("#save");

btn.addEventListener("click", () => {
  document.querySelector("#status")
          .textContent = "Saved ✓";
});

Right side is live — click Save and the virtual console logs the whole event. The button now DOES something: click fires, JS edits the page.

Four things every app does

JS reads and edits the DOM — the page's live tree of elements — so everything below is 'just' editing that tree.

The methods you'll see in every AI answer

You won't memorize these — but when AI writes them, you should recognize what each line is doing.

The three events that cover most UI

The pattern is always the same: listener → handler → edit the page. Only the event name changes.

A counter — state lives in a variable

Two buttons, one number. The JS variable is the truth; the page only mirrors it.

let count = 0;
const out = document.querySelector("#count");

document.querySelector("#plus")
  .addEventListener("click", () => {
    count += 1;
    out.textContent = count;
  });

document.querySelector("#reset")
  .addEventListener("click", () => {
    count = 0;
    out.textContent = count;
  });

Right side is live — click +1 / Reset; the console mirrors the data-then-paint order. That order is the idea behind every app framework.

Tabs — the real show/hide pattern

Show/hide is almost always just flipping a CSS class. JS never touches 'display' directly.

const tabs = document.querySelectorAll(".tab");

tabs.forEach(tab => tab.addEventListener("click", () => {
  tabs.forEach(t => t.classList.remove("active"));
  tab.classList.add("active");
  // CSS: .tab.active shows its panel, the rest hide
}));

Right side is live — click a tab; the console shows the .active class moving. The same trick powers dropdowns, toasts and accordions.

Form validation, the real way

Catch the submit, check the value, show or clear the error — without a page reload.

const form = document.querySelector("#signup");

form.addEventListener("submit", (e) => {
  e.preventDefault();                   // don't reload

  const email = document.querySelector("#email").value;
  const err = document.querySelector("#err");

  if (!email.includes("@")) {
    err.textContent = "That email looks wrong.";
  } else {
    err.textContent = "";              // clear it
    form.reset();
  }
});

Right side is live — submit a bad email, then a good one; the console logs each branch. This is the skeleton of every valid-email message.

Search a list on every keystroke

input → filter the data → re-render the list. This one pattern is behind every filter UI you've ever used.

const foods = ["Pizza", "Pho", "Sushi", "Banh mi", "Tacos"];
const input = document.querySelector("#search");
const list = document.querySelector("#list");

input.addEventListener("input", () => {
  const hits = foods.filter(f =>
    f.toLowerCase().includes(input.value.toLowerCase()));

  list.innerHTML = hits
    .map(f => "<li>" + f + "</li>")
    .join("");
});

Right side is live — type in the box and the console logs each filter. filter() picks matches, map() makes rows, join() glues them.

fetch — and always plan for failure

Networks fail: the server is down, the wifi drops, the route doesn't exist. The catch is part of the feature.

async function loadOrders() {
  const list = document.querySelector("#orders");
  try {
    const res = await fetch("/api/orders");
    const orders = await res.json();
    list.innerHTML = orders
      .map(o => "<li>" + o.name + "</li>")
      .join("");
  } catch (err) {
    list.textContent = "Couldn't load orders — retry?";
  }
}

Right side simulates the network (no real endpoint) — Load orders, or tick Simulate failure to hit the catch. Judge any AI fetch by its catch.

fetch doesn't block the page

This is why web apps feel alive while loading — and why async bugs feel spooky.

State + render() — the seed of React & Vue

Two pieces: one source of truth, and a function that repaints the page from it.

// one source of truth
let state = { open: 3, cart: [] };

// the page is a picture of the state
function render() {
  document.querySelector("#open").textContent = state.open;
  document.querySelector("#cart").textContent =
    "Cart: " + state.cart.length;
}

state.open += 1;   // 1. change the data
render();          // 2. repaint the page

Right side is live — the two buttons change state, render() repaints, the console logs it. This is exactly what React & Vue automate.

One element, three files

HTML, CSS and JS all talk about the same element — each does its own job.