Ninety courses. Six benches.

Margin, border, padding, and display, taught by drawing the boxes the browser is already drawing. You will stop adding wrappers to fix a gap you cannot name.

• Explain how margin, border, and padding add up
• Choose between block, inline, and inline-block
• Fix a collapsed margin without another wrapper

Specificity, inheritance, and the cascade, practiced on a stylesheet that has already gone wrong. You will learn to win a conflict by simplifying it.

• Predict which rule wins and say why
• Write a selector that does not depend on a long chain
• Reset a property without !important

Before this: The Box, on Purpose

A row, a stack, a toolbar, and the case where flex starts fighting you. You will know when to stop and reach for grid instead.

• Build a row that wraps without a media-query hack
• Align items on the cross axis on purpose
• Explain when flex is the wrong tool

Before this: The Box, on Purpose

Named areas, placement, and a breakpoint that changes the page without rewriting the markup. You will build a layout you could hand to a writer.

• Draw a page as named grid areas
• Place an item without absolute positioning
• Change the grid at a breakpoint without rewriting markup

Before this: Flow, Flex, and When Flex Fails

A display face and a text face, a measure that stays comfortable, and a scale small enough to remember. You will stop picking font sizes by eye.

• Set a measure that stays readable
• Build a type scale with a handful of sizes
• Pair a display face and a text face

Before this: The Box, on Purpose

Roles instead of hex values, and states that do not rely on color alone. You will check pairs against WCAG rather than against your monitor.

• Check a pair against WCAG contrast
• Design hover and focus without relying on color alone
• Name colors as roles, not as hex values

Before this: Type on a Screen

Every control gets a name, every error sits next to its field, and the form works from the keyboard. Advanced, because the details are where forms fail.

• Associate every control with a visible label
• Show an error next to the field it belongs to
• Complete the form from the keyboard alone

Before this: Selectors that Hold

You will choose breakpoints from the content, and use a container query where a viewport query is the wrong question.

• Choose a breakpoint from the content, not a device list
• Use a container query where a viewport query is wrong
• Let spacing scale without a pile of overrides

Before this: Grid for Pages, Not Demos

Animate a property that does not force layout, and honor prefers-reduced-motion as a requirement rather than a nicety.

• Animate a property that does not force layout
• Honor prefers-reduced-motion
• Use motion to show where something went

Before this: Color, Contrast, and States

You will give controls names a screen reader can announce, keep focus in visual order, and build a skip link that lands. Advanced, and it is the difference between a page that looks done and one that is.

• Give a control a name a screen reader can announce
• Keep focus order the same as visual order
• Build a skip link that actually lands

Before this: Forms People Can Finish

A theme as custom properties on a root, an override in one subtree, and a clear line between a variable and a preprocessor constant.

• Model a theme as custom properties on a root
• Override a token in one subtree
• Explain how a variable differs from a preprocessor constant

Before this: Color, Contrast, and States

Cascade layers, a naming scheme that does not explode, and a third-party widget that no longer restyles your page.

• Scope a component's CSS so it cannot leak
• Use a cascade layer to settle third-party styles
• Name a variant without a combinatorial class list

Before this: Selectors that Hold

You will be handed broken layouts and asked to name the winning rule before you change anything. Guessing is the habit this course is trying to retire.

• Find which rule is winning from the cascade panel
• Measure a box instead of guessing the gap
• Spot an overflow before it becomes a horizontal scroll

Before this: Grid for Pages, Not Demos

An empty state that says what to do, an error that names the failure, and a busy state that does not freeze the page. Twelve weeks, because these are product decisions as much as CSS.

• Design an empty state that tells the person what to do
• Write an error that names the failure and the next step
• Show progress without blocking the whole page

Before this: Forms People Can Finish

You choose the page. We hold the line on keyboard access, contrast, type, and a layout that works on a phone and a wide screen. You leave with notes another person could build from.

• Ship a page that works on a phone and a wide screen
• Pass a keyboard and contrast pass you run yourself
• Write notes another developer can build from

Before this: Names, Focus, and the Keyboard

Values, types, and control flow, written as small scripts that change a page. You finish able to read a tutorial without skipping the parts that look like noise.

• Run JavaScript in the browser and from a file
• Explain a value, a type, and a variable
• Read a short script and predict what it does

Scope, parameters, and return values, practiced until you can point at a variable and say what it holds. Closures get a proper course later; this is the ground they stand on.

• Predict what a name refers to at any line
• Write a function with a clear input and output
• Find a variable that leaked out of its block

Before this: JavaScript, in the Browser

Objects, arrays, destructuring, and the methods that replace most loops. You will reshape a tangled script into something you can read aloud.

• Choose between an array, an object, and a Map
• Replace most loops with map, filter, and reduce
• Pull nested values out without a long chain

Before this: Values, Scope, and Functions

A small interactive page and no dependencies. You will see the work a framework is doing for you, which makes the framework less mysterious later.

• Build an interactive page with no framework
• Create and update nodes without innerHTML soup
• Explain what a framework saves you from doing by hand

Before this: Objects, Arrays, and Methods

Bubbling, the event target, and one listener that serves a whole list. You will stop leaking listeners as a list grows.

• Use one listener for a list that changes
• Tell target from currentTarget
• Remove a listener when the node goes away

Before this: The DOM, No Framework

You will build a small promise so you can see what await is hiding, then add timeout, retry, and a rejection path that does not vanish.

• Run async work in parallel when it is safe
• Handle rejection, timeout, and cancellation
• Explain what await is waiting on

Before this: Events, and Who Handles Them

Call stack, tasks, microtasks, and timers. Advanced, because you will hand-trace mixed snippets and check yourself in the browser until the surprises stop.

• Predict the order of timers and promises mixed together
• Explain why a long loop freezes the page
• Break blocking work into chunks that keep the UI alive

Before this: Promises and async/await

Imports, the module graph, and a bundle that got too big. You will split the first load without treating the bundler as weather.

• Explain how a bundler resolves an import
• Split a bundle so the first page stays small
• Debug a build that produced the wrong file

Before this: Objects, Arrays, and Methods

Status codes, JSON, loading, and the empty response. You will stop treating the network as a function that always returns an array.

• Read a status code and decide what the UI should do
• Show loading and failure as designed states
• Cancel a request when the person navigates away

Before this: Promises and async/await

Advanced, because the platform already does more than most forms use. You will build one that works before any script runs, then improve it.

• Read a form with FormData
• Use constraint validation before custom script
• Submit without losing the person's input on failure

Before this: Events, and Who Handles Them

You will test an interface the way a person uses it, and learn what not to mock. A test that fails for a useless reason is treated as a bug.

• Write a test that survives an internal refactor
• Query the UI the way a person finds a control
• Diagnose a flaky test instead of retrying it

Before this: Promises and async/await

The prototype chain, classes, and the three ways to pin this. You will break it on purpose so the fix is a choice, not a superstition.

• Trace a property lookup up the prototype chain
• Say what this refers to at a call site
• Choose a class, a factory, or a plain object

Before this: Values, Scope, and Functions

Routing by hand, state in one place, and a render you can point at. The point is to feel the cost, so a framework later is a trade you understand.

• Hold UI state in one place you can name
• Render a view from that state
• Move between two screens without a framework router

Before this: The DOM, No Framework

Long tasks, the performance panel, and work that does not belong on the thread painting the page. You will measure before you rewrite.

• Find a long task in the performance panel
• Split work so input stays responsive
• Justify a change with a before-and-after trace

Before this: The Event Loop, Slowly

You pick the product. We cut scope until it ships: events, fetch, a form, and tests that describe what a person can do.

• Ship an interface with no UI framework
• Cover the critical path with behavior tests
• Show loading and failure without a blank screen

Before this: A UI with No Framework

Annotations, inference, and the first time the compiler is right and you are not. You finish comfortable leaving a file stricter than you found it.

• Add types to a small module without any
• Read a compiler error back to the real mismatch
• Let inference work where an annotation adds nothing

Unions, discriminants, and the checks that narrow them. You will stop using a cast to tell the compiler to trust you.

• Model a value as a union instead of optional fields
• Narrow a union with a check the compiler believes
• Remove a cast that was hiding a real case

Before this: Your First Typed File

Required, optional, and the union of variants. You will look at a props type and see the product decisions inside it.

• Design props that reject an illegal combination
• Choose a variant union over a pile of booleans
• Name a callback's arguments so the caller cannot drift

Before this: Unions and Narrowing

A beginner-length course on a single idea. The state object stops being a bag of flags that can all be true at once.

• Model loading, empty, ready, and failed as a union
• Render each state without checking three booleans
• Make the impossible combination a type error

Before this: Unions and Narrowing

Constraints, defaults, and inference sites, taught by removing duplication. Equal time goes to the overload that would have been clearer.

• Write a generic helper another person can call
• Add a constraint when the body needs one
• Prefer an overload when a generic is harder to read

Before this: Props as a Data Model

Menus, toasts, and form steps, each modeled so the render function is a switch the compiler can exhaust.

• Model a component as an exhaustive switch
• Add a variant without leaving a silent fall-through
• Keep the discriminant next to the data it describes

Before this: Types for Component State

Advanced. JSON, query strings, and form payloads arrive untyped no matter what your interfaces say. You will validate them and type the result, not the wish.

• Accept external data as unknown
• Parse it into a type the UI can trust
• Show a failure when the payload is not the shape you hoped

Before this: Unions and Narrowing

You will derive a type instead of copying it, and you will notice when the utility made the API harder to read.

• Derive a props variant with a utility type
• Read a mapped type and say what it produces
• Inline a utility when the name is hiding the shape

Before this: Generics You Can Read

ComponentType, props of a child, and a context value that cannot be undefined by accident.

• Type a context value so missing provider is a bug
• Describe children more tightly than ReactNode when you can
• Pass a component as a prop without losing its props

Before this: Props as a Data Model

Advanced. ExpectType-style checks and assertion functions. You will catch a type that got wider before a user catches the bug.

• Write a type-level assertion that fails the build
• Use a predicate to narrow, not a cast
• Notice when a public type got wider

Before this: Typing the Boundary

You will stop maintaining a type, a validator, and a default object as three drifting copies of the same form.

• Derive the value type from one schema
• Type field errors so a missing key is a compile error
• Submit a payload that matches the schema

Before this: Typing the Boundary

The React types people silence. You will type a change handler, a ref to a DOM node, and a list component that keeps the item type.

• Type an event handler without any
• Type a ref to the node you actually have
• Write a generic list that preserves the item type

Before this: Props as a Data Model

Public types, path exports, and a barrel file that accidentally became your API. You will draw a line and keep it.

• Mark a type as public or internal on purpose
• Stop a barrel file from widening your API
• Change an internal type without a downstream break

Before this: Utility Types in Anger

A button, a field, and a stack, with variant names that exist in exactly one place. Twelve weeks of making the system harder to misuse.

• Type a variant so a typo will not compile
• Share a token type between CSS and props
• Add a component without inventing a second naming scheme

Before this: React Types Without any

You bring a real file, or we give you one. The capstone is the diff: fewer casts, a parsed boundary, and a state union the render trusts.

• Replace a bag of flags with a state union
• Parse data at the boundary instead of casting it
• Leave a module another person can extend without any

Before this: Typing the Boundary

No state yet. You will build small components, pass data in, and see a render as a function of that data.

• Write a component as a function of its props
• Compose two components without copying markup
• Read a JSX tree and say what the DOM will be

Updates, batching, and the bug where you read state and expect it to have changed already. You will stop storing what you can derive.

• Update state without mutating the previous value
• Derive a value during render instead of storing it
• Explain why a state read can be stale

Before this: Components, from Scratch

Parent renders, state updates, and a component that rendered because its parent did. You will look at the commit rather than guessing.

• Say why a component rendered
• Lift state only as far as the components that need it
• Spot a render caused by a new object identity

Before this: State Is a Snapshot

A beginner course on one sharp edge. Index keys, stable ids, and the input that kept another row's text.

• Choose a key that matches the item's identity
• Explain what breaks when the key is the index
• Reset a row's state when the item actually changes

Before this: State Is a Snapshot

Controlled and uncontrolled, and the form that fights its user because both are trying to own the value.

• Handle an event without reading the DOM afterwards
• Make an input controlled for a reason
• Leave an input uncontrolled when state would add nothing

Before this: State Is a Snapshot

You will take a component full of flags and split it into pieces that compose. The API gets smaller on purpose.

• Replace a pile of boolean props with composition
• Pass a slot without cloning an element
• Keep a component's public API smaller than its internals

Before this: Components, from Scratch

Advanced. Server components, client boundaries, and the fetch that does not belong in an effect. You will draw the line before you write the file.

• Put a client boundary at the smallest component that needs it
• Fetch on the server when the data is ready there
• Explain what a client component ships to the browser

Before this: Rendering, and Why It Happened

Where the request lives, what happens on retry, and the race when the person navigates mid-flight.

• Render loading, error, and ready as separate UI
• Ignore a response that belongs to an old screen
• Retry without duplicating the request logic

Before this: Events and Controlled Inputs

Lifting state, composition, and context for something that is truly ambient. You will remove a provider that did not need to exist.

• Lift state to the nearest shared parent
• Use context for a value that is genuinely ambient
• Remove a provider that was hiding a prop

Before this: Composition over Flags

Advanced. Naming, dependencies, and the hook that became a second component with nowhere to put markup. You will put the logic back if the hook made it worse.

• Extract a hook that does one thing
• Name its inputs so the call site stays honest
• Test the behavior without mounting a whole screen

Before this: Sharing State on Purpose

Queries by role, user events, and the async UI. You will change the implementation and watch the test stay green for the right reason.

• Query a component the way a person finds it
• Assert on what changed on screen
• Refactor a component without rewriting its test

Before this: Events and Controlled Inputs

Measure a slow render, then decide. You will remove memoization that was copying props and calling it performance.

• Find a render that is actually expensive
• Memoize a value only when identity matters
• Delete a memo that was not earning its place

Before this: Rendering, and Why It Happened

A dialog that traps and restores focus, a button that is a button, and a live region that announces the change you just rendered.

• Move focus when a dialog opens and restore it on close
• Expose a name on a control you rendered
• Announce a status change without stealing focus

Before this: Composition over Flags

Button, field, stack, and dialog, documented by their props. Twelve weeks of making the next screen cheaper to build than the last.

• Build a component API another person can use without asking
• Share tokens between components
• Add a variant without a one-off class name

Before this: Composition over Flags

You choose the product. We hold the line on where state lives, what is tested, and whether a keyboard user can finish the main task.

• Ship a multi-screen React interface
• Cover the main task with tests a user could recognize
• Explain where each piece of state lives

Before this: Fetching for a Screen

Parser, render, and the script that blocked both. A short course for people who have built pages and never watched one load.

• Describe the path from response to first paint
• Find a script that blocked rendering
• Order assets so the page can paint sooner

Unused CSS, a bundle that grew a charting library for one page, and a split you can explain. Beginner on purpose: the habit starts early.

• Find code the first view does not need
• Split a route so it loads with its screen
• Say what the first load contains

Before this: How a Page Actually Loads

Dimensions, font loading, and a hero image that should not be the last thing on the wire. You will reserve the space before the bytes arrive.

• Reserve space so an image does not shift the page
• Load a font without hiding the text
• Prioritize the image the first view actually shows

Before this: How a Page Actually Loads

LCP, INP, and CLS, taken on a page you control. You will learn to distrust a single anecdote and keep the trace.

• Record a trace for a page you can reload
• Name which metric moved and which did not
• Compare two traces of the same flow

Before this: How a Page Actually Loads

Cache headers for assets, and the data request that should not be cached the same way. You will stop cache-busting everything out of fear.

• Cache a fingerprinted asset for a long time
• Keep a data request fresh when the screen must be
• Explain a stale UI as a caching choice

Before this: CSS and JS that Fit

A small token set, a naming scheme, and the drift that happens when the file and the drawing disagree. You will pick the file that wins.

• Name a token by role rather than by appearance
• Change a theme by changing tokens
• Point at one source when design and code disagree

Before this: Color, Contrast, and States

Advanced. Transform and opacity, and the height animation that forced layout on every frame. You will measure the frame, not the feeling.

• Animate on the compositor when the effect allows it
• Spot an animation that forces layout
• Drop motion that costs a frame and explains nothing

Before this: Motion that Respects People

A screen that still tells the truth when the request fails, including which part succeeded. You will write the copy with the layout.

• Show a failed request without a blank screen
• Keep the part of the page that still loaded
• Offer a next step that matches the failure

Before this: Empty, Error, and Busy States

Externalized copy, dates and numbers that follow the locale, and a layout that survives a longer word.

• Externalize a string instead of burying it in JSX
• Format a date and a number for the reader's locale
• Let a layout survive a longer translation

Before this: Type on a Screen

Advanced. Keyboard, names, contrast, and zoom, written down so the audit is a practice and not a one-time heroics. You will file issues a developer can close.

• Run a repeatable pass on one flow
• Write a finding that names the fix
• Re-test the finding after the change

Before this: Names, Focus, and the Keyboard

A single end-to-end test you trust, and the fixtures that keep it from being theatre. You will not try to automate the whole product.

• Automate one flow a person can finish
• Isolate the test data so the run is repeatable
• Read a failure as a product bug or a test bug

Before this: Tests that Watch Behavior

Versions, changesets, and a breaking change in a button that three products use. You will write the note the other teams needed.

• Version a component package on purpose
• Mark a breaking change before consumers hit it
• Migrate one consumer without a flag day

Before this: A Small Design System

Routing, server rendering, and the client boundary, on a framework you will actually deploy. The course is about the interface that ships, not about collecting frameworks.

• Render a page on the server when the data allows it
• Keep client JavaScript to the part that needs it
• Deploy the page and point at what the browser received

Before this: Server and Client UI

Client errors with enough context to reproduce, and a metric that moved after a deploy. Twelve weeks of watching a UI the way you watch a server.

• Capture a client error you can reproduce
• Tie a slow interaction to a release
• Decide whether a regression is worth rolling back

Before this: Measuring a Single Page

You bring a page or we give you one. The capstone is a before, an after, and a written reason for each change. Hope is not a result.

• Improve a page you measured before you touched it
• Keep a trace for every change you keep
• Write up what moved and what you left alone

Before this: Measuring a Single Page

Interfaces, not hours of 'coding.' You will describe an engagement as an outcome a buyer can recognize, and notice when you are selling time instead.

• Describe an offer as an outcome, not a pile of tasks
• Tell a frontend engagement from a generalist one
• Say no to work that is not the offer

Pages, states, and the things that are out. You will write a scope a client can disagree with before the work begins, which is the point.

• List the screens and states that are in scope
• Write exclusions a client can see
• Spot a request that changes the scope

Before this: What a Studio Sells

Weeks, risk, and the cost of revisions. You will put a price next to a scope and be able to say what would change it.

• Price from a written scope
• Name the risk that moved the number
• Change the price when the scope changes

Before this: Scoping an Engagement

A beginner pass at a statement of work for a frontend engagement: deliverables, assumptions, and a definition of done a designer and a client can both read.

• Write deliverables a client can check
• List the assumptions the price depends on
• Define done without a vague 'polish' line

Before this: Scoping an Engagement

A standing review, a short agenda, and notes that say what changed. You will stop collecting feedback in three chat threads.

• Run a review with an agenda
• Write down the decision, not only the comment
• Park feedback that is a new scope

Before this: A Statement of Work

A brief, access, review, and the work you still own. Hiring here means a contractor on a scoped interface, not building a department.

• Brief a contractor with the scope, not a vibe
• Review their interface work against that brief
• Keep client decisions in one place

Before this: The Weekly Client Review

Members, liability, and the difference between you and the company, taught with a frontend studio as the example. This is education for people who build interfaces. It is not legal, tax, or accounting advice, and it is not a substitute for a Missouri attorney or a CPA.

• Explain what an LLC separates from its members
• Name what forming one does not do by itself
• List the questions to take to an attorney before you file

Before this: What a Studio Sells

Ownership, votes, and what happens if a member leaves, walked through on a short agreement for a studio. This is education for people who build interfaces. It is not legal, tax, or accounting advice, and it is not a substitute for a Missouri attorney or a CPA.

• Find who owns what in an operating agreement
• Find how a decision gets made
• List the clauses you would ask a lawyer to explain

Before this: An LLC, in Plain Language

Assignment, license, and the portfolio exception, read as part of a client contract. This is education for people who build interfaces. It is not legal, tax, or accounting advice, and it is not a substitute for a Missouri attorney or a CPA.

• Tell an assignment from a license
• Find the clause that transfers the interface
• Ask for a portfolio right before the work starts

Before this: A Statement of Work

Deposits, milestones, and a simple set of books for a studio LLC. Advanced only because the habits are exact. This is education for people who build interfaces. It is not legal, tax, or accounting advice, and it is not a substitute for a Missouri attorney or a CPA.

• Invoice from the company, not from a personal note
• Tie a payment to a milestone in the scope
• Keep a record you could hand to a bookkeeper

Before this: Pricing Frontend Work

A tech lead's week on a small frontend team. Critique, sequencing, and the call that is still yours when the group disagrees.

• Split an interface across three people without collisions
• Run a critique that changes the work
• Name the decision you are not delegating

Before this: Your First Contractor

Ranges, unknowns, and the update you send when the range was wrong. The estimate is a communication, not a promise you whisper.

• Give a range and the assumption under it
• Surface an unknown before it becomes a slip
• Update the estimate in writing when the assumption breaks

Before this: Pricing Frontend Work

Interface critique, a written note, and a follow-up that checks the change landed. Eleven weeks of making review a practice instead of a performance.

• Run a critique with a question, not a tour
• Write the change you expect to see
• Check that the change landed

Before this: The Weekly Client Review

Roles, a second lead, and the client relationship that still sits with the company. Twelve weeks on growing past the founder without pretending you are a large firm.

• Name the work that should leave your desk
• Hand a client relationship to the company, not to chaos
• Write a role before you hire for a vibe

Before this: Leading a Frontend Trio

You will leave with an offer, a sample scope, a price, a list of operating-agreement questions, and a checklist of what you will not decide alone. This is education for people who build interfaces. It is not legal, tax, or accounting advice, and it is not a substitute for a Missouri attorney or a CPA.

• Write the offer the studio will sell
• Attach a scope and a price to that offer
• List the formation questions you will take to a lawyer

Before this: An LLC, in Plain Language