Frontend Dev – Get Started

August 1, 20265 min readUpdated 8/20/2026

Every app you use has a part you can see and a part you cannot. The part you can see is the frontend: it draws the interface, holds what the person has half-finished, decides what happens when they tap something, and stays usable on a five-year-old phone on a train. This track is about becoming the person who builds that.

It is a roadmap, not a reference. Twelve posts, each one topic, in the order the topics actually become useful. Read it once end to end and you will know what you need to learn, why each piece exists, and which of the deeper tracks on this site to go and read next.

Who this is for

  • You can write some code and you want to know what a frontend job actually consists of.
  • You are self-taught and suspect there are large gaps — there are, and this names them.
  • You have been doing backend work and want to move across.
  • You are about to interview and want the shape of the whole thing, not one framework's API.

You need to be able to write and run a program in some language. Nothing else is assumed.

What a frontend actually does

Strip away the vocabulary and a frontend is also a loop, just pointed the other way. Something happens — a tap, a keystroke, a page load — you work out what it means, you fetch or change some data over the network, and you redraw enough of the screen to reflect it.

Here is one real interaction from the app this track uses — a customer signing in:

StepWhat happensPost
1The browser parses HTML into a DOM and CSS into a CSSOM, then lays out and paints3
2The framework mounts a component tree and renders the sign-in form5
3Each keystroke updates state, and the input redraws from that state6
4Submit is intercepted so the browser does not navigate away8
5POST /api/auth/login goes out and one of four things comes back7
6The returned token is stored, and the app now knows who this is9
7A redirect sends them back to the page they were originally trying to reach8
8The admin screens they can now see are a separate download, fetched on demand10

Every post in this track is one of those steps, or the thing that makes the steps possible.

The twelve posts

  1. Get Started — this one.
  2. What a Frontend Engineer Actually Does — the job, and where the line sits between you and everyone else.
  3. The HTML, CSS and Browser You Actually Need — the platform every framework is built on top of.
  4. The JavaScript and TypeScript You Actually Need — the subset of the language that matters here, which is not the subset a beginner course teaches.
  5. What to Learn in a Framework — the small part of a big framework you use every day.
  6. State Management — where a value should live, which is what most frontend bugs are really about.
  7. Talking to the Backend — one request, four outcomes, and the three that beginners forget.
  8. Routing, Forms and Validation — the URL is state, and forms are where users actually touch the app.
  9. Authentication and Security in the Browser — everything you ship is public, so what can a frontend actually enforce.
  10. Performance and Accessibility — two names for one question: can this person actually use it.
  11. Testing — how you change code you did not write without being afraid.
  12. Build Tooling and Deployment — what turns your source into files a browser downloads, and how they get somewhere real.

The stack every example uses

The ideas in this track are not React-specific — Vue, Svelte and Angular answer the same questions with different syntax. But a roadmap made entirely of abstractions is useless, so every example is real code from one working app, and that app is this:

PieceVersionWhy this one
React19.2.8The framework with the largest job market, so the examples are the ones you are most likely to meet.
TypeScript6.0.2Effectively the default for new frontend work. Post 4 argues why.
Vite8.2.0The build tool. Post 12 explains what it does.
React Router7.18.2Routing, post 8.
Redux Toolkit2.12.0Used on half the app. Post 6 explains the half it is not used on, which is the more interesting half.
Bootstrap5.3.8A component library, so the posts are not about hand-rolling a dropdown.
Playwright1.62.1End-to-end tests, post 11.

Every version above is read off the app's package.json rather than from memory. If a number here disagrees with the app, the app is right.

Where the code comes from

The samples are lifted from a pizza ordering app — a menu, a cart, guest and signed-in checkout, a customer's order history, and an admin area behind a role check. It is deliberately big enough to have the problems real apps have: two kinds of user, money, async work, and screens that most visitors never open.

Snippets are edited for the page — comments reflowed, unrelated branches elided with ... — but never invented. Where a post shows you something, that something compiles and runs.

When to stop reading this and go deeper

This track's job is to tell you what to learn and roughly why. It is deliberately not the place that teaches you flexbox. When a post names a topic and you want the hands-on version, these are where to go:

When you wantGo to
Markup, forms, the head section, SEOHTML — 12 posts
Selectors, the box model, grid, flexbox, media queriesCSS — 21 posts
The language itself — objects, promises, modules, thisJavaScript — 19 posts
React in depth — hooks, context, routing, memoisationReact — 27 posts
The same job from the other side of the APIBackend Development — 10 posts
Mobile with the same languageReact Native — 5 posts
How large systems fit togetherSystem Design — 7 posts

A reasonable way to use all of it: read this track straight through in an afternoon without writing any code, then start building something and drop into the deeper tracks whenever you hit a topic you cannot fake.

The one thing to take from this post

Frontend work looks like it is about appearance and is mostly about state — what is true right now, where that truth lives, and what has to be redrawn when it changes. Design hands you a picture of one moment. Your job is every other moment: while it is loading, when it failed, when the list is empty, when the person has typed half of something and switched tabs.

Next: What a Frontend Engineer Actually Does.