Building Applications · Single Page Apps · Part 2 of 2

Building your SPA: from blueprint to running app

Last time you designed the intent. Today Claude Code builds it, and you stay the architect.

Today

What a single page application is, and how to catch one in the wild
Our stack: Node, npm, Vite, React, React Router. Who does what.
Equip Claude Code: MCP servers and design skills
Turn your wireframes into an app_outline/ and build in phases, live
Save it with git, and package it as a reusable sub-agent

A single page application loads one HTML page once, then updates parts of it as you click

Traditional website

Every click asks the server for a brand-new page. The screen flashes, scroll resets, anything you typed is gone.

Single page app

The app loads once. Clicking swaps only the part that changed. Instant, smooth, and state survives.

Activity: SPA Detective

Warm-up: the same radio site, built both ways. Watch the music timer.
I visit real sites and click around
In chat, on "go": SPA or TRAD?
Then we check the evidence in DevTools

Page: activity-spa-detective/index.html

Warm-up (2 min): KSPA 101.5 is a made-up radio station site, built twice. Its two links are at the top of the SPA Detective page, under "Warm-up". Open KSPA, traditional version first. (No audio plays; the "music" is a counting timer.) Hit Listen live, type in Request a song, click Home. The timer resets, text is gone, and the "documents loaded" counter goes up. Then the SPA version: the music keeps going, the text survives, and the document timestamp never changes. "Same site. The only difference is how navigation works."

Lineup (3 min), just three sites: YouTube (SPA: the video keeps playing), Wikipedia (TRAD: open DevTools → Network → Doc, click a link, a new row appears = full page load), then our curriculum site (TRAD, the fun reveal). For each: do the action, count down, everyone answers in chat. The rest of the table is extra if you're ahead.

Wrap with the three clues at the top of the page: the flash, things survive, DevTools proof.

Good moments: the curriculum site is traditional (MkDocs static pages). GitHub is mostly a SPA now (Issues, PRs and Code tabs load no new document), but a few pages still full-load: "it's a spectrum, not a binary." Netflix is the homework clone.

Press K on that page to show verdicts.

Tech stack: Node engine, npm parts store, Vite workshop, React lego bricks, React Router receptionist

diagrams/L2-01-tech-stack.tldr

Open with: "You won't write this code. You do need to know who's responsible for what. That's how you steer Claude, and how you know where to look when something breaks."

Bottom up:

Node runs JavaScript outside the browser (your laptop). Everything below depends on it.
npm comes with Node and installs packages (React, Vite, Router). package.json is the shopping list plus scripts like npm run dev.
Vite creates the project, runs the fast dev server (localhost:5173), and builds for production.
React builds the UI from reusable components and updates only what changed.
React Router DOM looks at the URL and decides which component to show, without reloading.

One-liner to repeat: "Node runs your JavaScript, npm manages what your project depends on."

React builds the screen out of components

A component is a reusable piece of UI: a button, a workout card, a navbar.

Build a <WorkoutCard> once, use it on Home and History.

When data changes, React updates only that part of the page.

Not automatically "the best," but popular, flexible, huge ecosystem, and it pairs well with Vite and Router.

// a component is a function that returns UI
function WorkoutCard({ name, date }) {
  return (
    <div className="card">
      <h3>{name}</h3>
      <p>{date}</p>
    </div>
  )
}

React Router reads the URL and swaps one component into the outlet while the navbar and footer stay

diagrams/L2-02-router-shell.tldr

Start the project: Vite does the scaffolding

npm create vite@latest
# Project name:    liftlog
# Framework:       React
# Variant:         JavaScript
# Linter:          Oxlint (either is fine)
# Install + start: No

cd liftlog
npm install
npm install react-router-dom
npm run dev
# → http://localhost:5173

Or just ask Claude

"Create a React + Vite project with react-router-dom using npm, named liftlog, and run it on the dev server."

Either way you get the same files. We won't deep-dive into them.

Claude Code receives context from app_outline, rules from skills, abilities from MCP servers, and can be packaged as a sub-agent

diagrams/L2-03-toolbelt.tldr

MCP servers give Claude abilities

Context7

Pulls the latest docs for our stack, so no deprecated functions.

Playwright

Drives a real browser: clicks, types, screenshots. It checks pages against your wireframes.

Chrome DevTools

Reads the console, network, and performance. Debugging beyond what's visible.

claude mcp add --scope user playwright      -- npx -y @playwright/mcp@latest
claude mcp add --scope user context7        -- npx -y @upstash/context7-mcp
claude mcp add --scope user chrome-devtools -- npx -y chrome-devtools-mcp@latest
# check:  claude mcp list

Skills are rulebooks that push Claude past generic AI design

frontend-design: Anthropic's official skill. Distinctive type, palette, layout.
ui-ux-pro-max: UI/UX rules, component patterns, responsive layout
taste: dials for variance and density, bans the "AI slop" defaults
design-motion-principles: easing, timing, micro-interactions

Install: the one-liner on the class site. Check: /skills

your-project/
├── .claude/
│   └── skills/
│       ├── frontend-design/
│       │   └── SKILL.md
│       ├── ui-ux-pro-max/
│       │   ├── SKILL.md
│       │   ├── data/      ← 70+ files!
│       │   └── scripts/
│       ├── taste-skill/
│       └── design-motion-principles/
│           ├── SKILL.md
│           └── references/
└── ...

app_outline folder structure mapped to its purpose

diagrams/L2-05-app-outline.tldr

The prompt: every part has a job

Stack

React + Vite, React Router with BrowserRouter

Skills

Name all four, so Claude uses them

Constraint

No API. Data lives in the browser and refresh resets it.

Context

Read user_journey → app.png → each page's wireframe + story → style guide

Docs

Use Context7 for current conventions

Verify

Playwright screenshot of each page, compared to its wireframe

Phases

Claude proposes phases + pass conditions. You approve each one.

Confirm first

Summarize the journey and list pages before any code

Full text: demo-kit/prompt.md. Paste it now and let Claude start.

Build loop: plan, build one phase, screenshot, compare with wireframe, you approve, git commit, next phase

diagrams/L2-04-build-loop.tldr

Activity: Who's responsible? (while Claude builds)

I show a problem you'll actually hit this week
Type which tool is responsible: Node, npm, Vite, React, Router, an MCP, a skill, app_outline, git…
Hit enter on "go." Then we reveal.

Page: activity-whos-responsible/index.html

Back to Claude · unmute or chat

Does phase 1 match the wireframe? What feedback would you give Claude before approving?

Compare the Playwright screenshot to home.png. Look at layout, missing elements, empty state.

Version control: every approved phase is a save point

# in Claude: save what it learned
/init                # writes CLAUDE.md

git init
git add -A
git commit -m "Phase 1: app shell + Home"

# create the GitHub repo and push
gh repo create liftlog --public --source=. --push

Why it matters

Phase 3 broke everything? Go back to phase 2.
Share your code with teammates and instructors
Your Claude sessions come and go. The repo stays.
CLAUDE.md is the first thing Claude reads next session

/init first. Claude in terminal 2 is busy with phase 2, so open a third terminal in ~/demos/liftlog, run claude, type /init, and approve the CLAUDE.md write. Scroll through it out loud: "Tomorrow I close this terminal and Claude forgets everything. This file is what it reads first next time." It now describes the real app (routes, folders, browser-only state, commands), which is why we waited until after phase 1. Short on time? Skip it and just say it. Then /exit.

Then git, live. In that same third terminal in ~/demos/liftlog and run the three git lines (the project isn't a git repo yet). Vite already made a .gitignore, so node_modules stays out. You can also ask Claude: "commit this phase with a descriptive message."

Explain gh repo create instead of running it, unless you want a public repo of the demo.

Package it as a front-end sub-agent

# .claude/agents/front-end-agent.md
---
name: front-end-agent
description: Builds, maintains, and tests React
  SPAs with responsive, accessible UI/UX.
model: sonnet
mcpServers:
  - context7
  - playwright
  - chrome-devtools
skills:
  - frontend-design
  - ui-ux-pro-max
  - design-taste-frontend
  - design-motion-principles
---
You are a Senior Front-End Engineer…

Set it up once, reuse it everywhere

A specialist teammate that already knows its skills, MCPs, and workflow: analyze → plan → implement → test → document.

skills: uses each skill's name. Taste's name is design-taste-frontend.

Homework, Part II

Priority 1, build your app: turn your Part I planning into an app_outline/ and build the front-end SPA
Priority 2, FreeCodeCamp: 100 steps of the JavaScript certification
Priority 3, Netflix clone: use Claude Code, skills, context, and MCPs to build your SPA

Checklist: skills folder ✓ · MCPs connected ✓ · app_outline ✓ · phases approved ✓ · pushed to GitHub ✓

Exit ticket · in chat

Name one thing you'll put in your app_outline that Claude couldn't have guessed.

That's the part only you can do.