Start from zero: what frontend architecture actually is
Frontend architecture is the discipline of moving from a page to an application. This is the zero-level map and the eight words — component, state, props, re-render, data fetching, client vs server, bundler, component tree — that every senior unit assumes you know.
You can write HTML. You can sprinkle some JavaScript onto a page to make a button flash or a menu open. That is a page. Now imagine keeping track of which items are in a shopping cart, which user is logged in, whether a modal is open, what the server just returned — across dozens of interactive pieces — while the design team keeps adding features. That is an application. The gap between the two is not a bigger script tag. It is architecture: a set of decisions about how the pieces of your UI are structured, how they share information, and how your code travels from your editor to a browser anywhere on earth. This lesson is the map before the climb.
The one shift that changes everything
A web page is mostly static: HTML arrives, a bit of JS runs, done. An application is a living thing: it holds data that changes over time, re-draws parts of itself in response, and talks to servers without reloading. That shift — from document to application — is what frontend architecture addresses. Get it right and a team of ten can add features without stepping on each other. Get it wrong and every new feature is a game of “who broke the cart?”
When you hit your first bug where clicking one button breaks an unrelated part of the screen, you will want a mental model for why — and this is it.
The good news: the entire discipline rests on one equation. UI is a function of state. Everything else is detail on top of that.
The eight words the rest of the track assumes
The senior units that follow drop these terms without stopping to define them. Here they are, one sentence each — what it is and why it exists.
| Word | What it is | Why it exists |
|---|---|---|
| Component | A self-contained piece of UI — a button, a card, a whole page — written as a function. | So you build once and reuse everywhere, instead of copy-pasting HTML. |
| State | Data that can change over time and that the UI needs to reflect immediately. | So the app “remembers” things — cart items, login status, open modals — without a page reload. |
| Props | Values passed from a parent component into a child, like arguments to a function. | So a reusable component can render differently depending on what the caller provides. |
| Re-render | The framework running your component function again to produce an updated UI. | So the screen stays in sync with state automatically — you never touch the DOM by hand. |
| Data fetching | Requesting data from a server (or API) and putting it into state. | So your UI shows real, live information instead of only what was baked into the HTML. |
| Client vs server | Whether code runs in the user’s browser (client) or on your machine in a data centre (server). | So you know where secrets, databases, and heavy logic should live — and where they must not. |
| Bundler | A tool (e.g. Vite, webpack) that merges your many source files into optimised files the browser loads. | So you write clean, modular code in dev and ship fast, small files in production. |
| Component tree | The parent-child hierarchy of all the components that make up a page. | So you can reason about where state lives, how props flow down, and what re-renders when. |
How they fit together
Read in order, the words tell one story: you write components — each a pure function of its props and state — and nest them into a component tree. When a user acts, state changes. The framework re-renders the affected components automatically. Somewhere in the tree a component does data fetching, pulling live data from the server into local state. Your bundler takes all of this — hundreds of source files, libraries, styles — and produces the small, optimised bundles a browser can actually load. That single paragraph is the entire track in miniature; every later unit zooms into one of those steps.
▸Why this works
Why not just keep doing “vanilla JS”? Because unstructured code does not scale. When every part of the page reaches into the DOM and mutates it directly, no one can predict what will change and when. A component model with explicit state and one-directional data flow makes behaviour predictable: you know that a component only changes its own DOM, and only in response to its own state or the props its parent chose to give it. That predictability is what lets a team of twenty ship features without permanent firefighting.
You do not need to memorise this
Two honest notes before the climb. First: nobody holds all of this at once on day one — you will meet each word again, in depth, in its own unit, and it will stick then. This page is a coat-hook to hang the details on, not a test. Second: not every project needs every concept. A small marketing site may have almost no state and no bundler config to speak of. The senior track teaches the full picture because that is what a production app at scale demands — but “start simple, add complexity when the pain shows up” is itself the senior instinct.
What is the core equation that all frontend architecture rests on?
Order the journey from a user action to an updated screen:
- 1 User acts (clicks a button, submits a form)
- 2 State changes in the component that owns it
- 3 Framework re-renders affected components in the tree
- 4 Updated UI appears in the browser
- 01In one breath: what is the core equation of frontend architecture, and what does each term mean?
- 02What is the difference between props and state, and why does it matter?
Frontend architecture is one idea with a lot of machinery hung off it: UI is a function of state, and everything else is infrastructure to make that equation work at scale. The structural half is the component tree — components that receive props, hold state, and re-render automatically when state changes, so you never touch the DOM by hand. The operational half is data fetching (pulling live data from a server into state) and the client-vs-server boundary (knowing where code can safely run). The build half is the bundler, which turns your modular source files into the small, fast files a browser actually loads. You do not need to hold all eight words at once — each gets its own unit ahead. Now when you read a PR description that says “lifting state caused unnecessary re-renders,” you will know exactly which three of these eight words to reach for first.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.
Apply this
Put this lesson to work on a real build.