Frontend engineer roadmap
Every stage applies. It starts with what the browser does when a page loads, covers HTML, CSS and JavaScript in depth, then frameworks, and ends with rendering, performance, accessibility and designing a frontend in an interview. Start here if you are not sure which path fits.
Core and recommended topics. Optional ones stay hidden until you have built a few real interfaces.
- Core: needed for most jobs of this kind
- Recommended: worth learning early
- Optional: learn it when your work needs it
Stage 1
How the web loads
Many frontend problems start below the framework. To fix a slow Largest Contentful Paint or a slow hydration, you need to know what happens to a request: DNS, TLS and HTTP, then the browser parsing HTML, building the DOM and CSSOM, and painting. Frameworks run on top of all of this.
Core: What happens during a request
DNS lookup, the TCP and TLS handshakes, the HTTP request and the response. Knowing these lets you turn "the site is slow" into something specific, such as an 800 ms time to first byte caused by the origin server.
GuideHow HTTP works SimulatorRequest flow SimulatorTCP handshake Outside linkMDN: HTTP overview CodexNetworking
Core: The critical rendering path
How the browser turns bytes into pixels: HTML into the DOM, CSS into the CSSOM, then the render tree, layout, paint and compositing. Render-blocking CSS and JavaScript are the main things you can change.
Outside linkMDN: how browsers work Outside linkweb.dev: rendering on the web Outside linkweb.dev: critical rendering path
Recommended: DNS and CDNs
DNS turns names into addresses, and a CDN serves static files from a location near the user instead of your origin server. Where your files are served from accounts for a large part of load time.
GuideHow DNS works SimulatorDNS resolution GuideHow a CDN works Outside linkCloudflare: what is a CDN
Recommended: HTTPS and TLS
Production sites are served over TLS. Mixed content, HSTS and certificate errors become frontend problems as soon as the browser blocks a request.
Stage 2
HTML and semantics
Good HTML is the cheapest way to improve accessibility and search results. The right element comes with keyboard behaviour, screen-reader semantics and form handling built in. Use a <div> instead and you have to rebuild all of that yourself.
Core: Semantic elements
Landmarks, headings, lists, and when to use
<button>or<a>. The element you choose tells the browser and assistive technology what the content is.Outside linkMDN: HTML elements reference Outside linkweb.dev: learn HTML Outside linkMDN: HTML basics
Core: Forms and inputs
Built-in validation, input types, labels and submission. Many form libraries reimplement things the browser already does correctly.
Recommended: Accessible markup
Roles, names and states. ARIA fills gaps where HTML cannot describe something, and the first rule of ARIA is not to use it when a native element already does the job.
Outside linkMDN: ARIA Outside linkW3C: ARIA Authoring Practices
Recommended: Metadata and SEO
Title, meta description, Open Graph tags, canonical URLs and structured data. Search engines and link previews read these before running any JavaScript.
Outside linkGoogle Search Central docs Outside linkMDN: the document head
Stage 3
CSS and layout
CSS is a layout system with rules for resolving conflicts, not decoration added at the end. Once the cascade, the box model and the difference between Flexbox and Grid make sense, most CSS problems turn out to be a choice of the wrong layout tool.
Core: The cascade, specificity and inheritance
Why one rule wins over another: specificity, source order, inheritance and cascade layers. This is what is really happening when
!importantappears to fix something.Outside linkMDN: the cascade Outside linkweb.dev: learn CSS Outside linkMDN: specificity
Core: The box model
Content, padding, border, margin and
box-sizing. Margin collapsing and the difference betweencontent-boxandborder-boxexplain most unexpected gaps.Outside linkMDN: the box model Outside linkCSS-Tricks: box-sizing
Core: Flexbox
Layout in one direction, a row or a column, with control over alignment and spacing. The usual choice for laying out the inside of a component.
Outside linkCSS-Tricks: a guide to Flexbox Outside linkMDN: flexbox Outside linkFlexbox Froggy
Core: Grid
Layout in rows and columns at the same time. Page layouts get much simpler once you use Grid for them instead of nesting Flexbox.
Outside linkCSS-Tricks: complete guide to Grid Outside linkMDN: CSS grid layout Outside linkGrid Garden
Recommended: Responsive design
Media queries,
clamp(), container queries and intrinsic sizing, which let layouts adapt to any width instead of three fixed breakpoints.Outside linkMDN: responsive design Outside linkweb.dev: learn responsive design Outside linkMDN: container queries
Stage 4
JavaScript
Every framework is JavaScript with conventions on top. Closures, the prototype chain and the event loop explain why a callback saw an old value, why this is undefined, and why an await did not pause what you expected.
Core: Types, coercion and equality
Primitives and objects,
==and===, truthiness, and the type coercion rules behind many unexpected results.CodexJavaScript Outside linkjavascript.info Outside linkMDN: equality comparisons
Core: Scope and closures
Lexical scope, hoisting, and closures, which capture a variable rather than its value at the time. Interviews test this often, and it causes the stale-closure bugs common in React.
Outside linkMDN: closures Outside linkYou Don't Know JS: Scope & Closures
Core: Prototypes and this
The prototype chain, how
thisis set when a function is called, and why arrow functions do not have their own. Classes are built on this object model.Outside linkMDN: inheritance & the prototype chain Outside linkMDN: this
Core: Promises, async/await and the event loop
The call stack, the task and microtask queues, and why a promise callback runs before a
setTimeout(0). You need this model for anything that waits on the network.SimulatorEvent loop CodexThe event loop GuideHow event loops work Outside linkMDN: the event loop
Recommended: Modules
ES modules, named and default exports, dynamic
import()and tree-shaking: how code is split, loaded and stripped of unused parts.Outside linkMDN: JavaScript modules CodexV8 engine internals
Stage 5
TypeScript
Most large frontends use TypeScript. Its value is in describing the shapes your data can take, so that many bugs fail to compile. Narrowing and generics are the features that make the biggest difference.
Core: Types and inference
Structural typing, inference, unions and literal types. Let the compiler infer most types and annotate the boundaries: props, API responses and function signatures.
Outside linkTypeScript handbook Outside linkTypeScript: everyday types
Core: Narrowing
typeof,in, discriminated unions and type guards. The compiler follows your branches so a value has the right type inside each one.Outside linkTypeScript: narrowing Outside linkTotal TypeScript (Matt Pocock)
Recommended: Generics
Functions and types that take other types as parameters. They make reusable component APIs possible without falling back to
any.Outside linkTypeScript: generics Outside linktype-challenges
Stage 6
The DOM and browser APIs
Frameworks hide the DOM until you need a ref, an event listener, a focus trap or a third-party script. The DOM, events, fetch, storage and the browser's security rules (CORS, XSS, CSP) are the platform every framework is built on.
Core: The DOM
Nodes, the tree, querying and changing it. It is what React's virtual DOM is compared against, and what you touch directly through a ref.
Outside linkMDN: the DOM Outside linkMDN: manipulating documents
Core: Events, bubbling and delegation
Capture and bubble phases, and event delegation, where one listener on a parent handles events from many children. Framework click handlers are built on this.
Outside linkMDN: introduction to events Outside linkjavascript.info: bubbling and capturing
Core: Fetch
fetch,RequestandResponse,AbortControllerand streaming responses: how data reaches the page, and how to cancel a request when a component unmounts.Recommended: CORS and the same-origin policy
Why a request works from a command-line tool but fails in the browser: preflight requests, allowed origins and credentials. Most frontend developers run into this at some point.
Recommended: Cookies, localStorage and IndexedDB
What each stores, the size limits and the security trade-offs. Cookies are sent with every request; localStorage can be read by any script on the page.
Outside linkMDN: client-side storage Outside linkweb.dev: storage for the web
Recommended: XSS and Content Security Policy
The browser runs any script that ends up in the page. Encoding output, setting a Content Security Policy and avoiding
innerHTMLwith untrusted data prevent cross-site scripting.Outside linkOWASP: XSS prevention cheat sheet Outside linkMDN: Content Security Policy (CSP) CodexSecurity
Stage 7
Version control and collaboration
Everyone uses Git, but there is a large gap between making commits and confidently rebasing a messy branch or reviewing a 40-file pull request. Learn how Git stores history, not only the commands.
Core: Git fundamentals
Commits, branches, the staging area, and how Git stores snapshots. Seeing history as a graph of commits makes the more advanced commands much less risky.
GuideHow Git works Outside linkPro Git (free book) Outside linkLearn Git Branching (interactive) Outside linkAtlassian Git tutorials
Core: Branches and pull requests
Feature branches, trunk-based development, and the pull request as the unit of review.
Recommended: Rebase and merge
When to rewrite history for a clean line and when to keep it. Tidying a branch with an interactive rebase before review makes it easier to read.
Outside linkAtlassian: merging vs rebasing Outside linkOh Shit, Git!?!
Stage 8
Build tools and packages
A bundler resolves modules, a transpiler converts newer syntax for older browsers, and a dev server reloads changes instantly. You will rarely configure these from scratch, but when the build breaks you need to know which tool does what.
Core: Package managers
npm, pnpm and Yarn, lockfiles, semver ranges and how
node_modulesis resolved. pnpm's shared content-addressed store saves disk space and install time in large monorepos.Outside linknpm docs Outside linkpnpm docs Outside linknpm: about semantic versioning
Core: Bundlers and dev servers
Vite for most new projects, with esbuild and Rollup inside it, and webpack in many older ones. A bundler takes the module graph and produces optimised bundles, with hot module replacement during development.
Outside linkVite docs Outside linkesbuild Outside linkRollup Outside linkwebpack concepts
Recommended: Transpilers
Babel and SWC convert modern JavaScript, TypeScript and JSX into code your target browsers can run. Browserslist sets which browsers those are.
Outside linkBabel docs Outside linkSWC Outside linkBrowserslist
Recommended: Linting and formatting
ESLint catches mistakes and Prettier handles formatting, so reviews discuss logic instead of style. Run both in the editor and in CI.
Stage 9, pick one
Pick a framework
Jobs ask for fluency in one component framework. React is the common default because most jobs use it. Vue and Svelte are well liked and increasingly in demand, and Angular runs many large company frontends. Pick one you can build and debug quickly; the concepts carry over.
Core: React
Components, JSX, hooks and the rules of hooks. React has the largest ecosystem and the most job openings.
Outside linkReact: learn Outside linkReact: reference Outside linkReact: thinking in React
Core: Components and reactivity
Props passed down, events passed up, derived state, and how each framework tracks what changed. These ideas apply whichever framework you choose.
Outside linkPatterns.dev Outside linkReact: state as a snapshot
Recommended: Vue
Well documented and easy to start with. The Composition API, single-file components, and a reactivity system many people find simpler than hooks.
Recommended: Svelte
A compiler that turns components into plain JavaScript at build time, with less boilerplate and fine-grained reactivity. SvelteKit adds routing and server rendering.
Outside linkSvelte: tutorial Outside linkSvelte docs Outside linkSvelteKit docs
Stage 10
State and data fetching
Much frontend complexity is state: where it lives, who owns it and how it stays in sync with the server. A useful change in recent years is separating server state (cached, asynchronous, shared) from client state (UI and short-lived), instead of putting everything in one global store.
Core: Local, lifted and global state
Keep state as close as possible to where it is used, lift it up only when components share it, and use a global store last. Many cases where a team thinks it needs Redux are state kept in the wrong place.
Outside linkReact: managing state Outside linkReact: choosing the state structure
Core: Server state and caching
TanStack Query and SWR treat the server as the source of truth and handle fetching, caching, revalidation and background updates. They often remove a large amount of state code.
Recommended: Global stores
Redux Toolkit for large, explicit state, and Zustand or Jotai for smaller stores built around hooks. Choose by how much structure the team needs.
Outside linkRedux Toolkit Outside linkZustand Outside linkJotai
Recommended: Forms
Controlled and uncontrolled inputs, validation and submission state. A library such as React Hook Form helps without reimplementing what the browser already does.
Outside linkReact Hook Form Outside linkZod (schema validation)
Stage 11
Styling and design systems
Writing CSS for one page is easy. Keeping styles consistent across hundreds of components and several teams is harder. Utility classes, scoped styles, design tokens and component libraries all address that problem through constraints and reuse.
Core: CSS architecture and scoping
BEM, utility classes and CSS Modules: ways to stop styles leaking between components in a large codebase.
Outside linkMDN: organizing CSS Outside linkBEM methodology Outside linkCSS Modules
Core: Utility-first CSS with Tailwind
Style elements with small utility classes in the markup, limited to values set in the configuration. No class names to invent and no unused CSS. Many new projects use it.
Outside linkTailwind CSS docs Outside linkTailwind: core concepts
Recommended: CSS-in-JS
styled-components and Emotion keep styles next to components and generate them at runtime; vanilla-extract and similar tools do the work at build time instead.
Outside linkstyled-components docs Outside linkvanilla-extract
Recommended: Design tokens
Colours, spacing and type sizes as named values shared between design tools and code, so a rebrand changes the tokens rather than every component.
Outside linkDesign Tokens (W3C community group) Outside linkStorybook docs
Stage 12
Rendering and architecture
The biggest architectural choice in a frontend is where pages are rendered: in the browser, on the server for each request, at build time, or a streamed mix. Each affects how soon content appears, when the page becomes interactive and what infrastructure you run. Senior interviews often focus here.
Core: SPA, MPA, SSR and SSG
Single-page apps suit highly interactive applications, server rendering gives a fast first paint and good SEO, and static generation suits content that rarely changes.
Outside linkweb.dev: rendering on the web Outside linkPatterns.dev: rendering patterns
Core: Server rendering, static generation and revalidation
Rendering HTML on the server or at build time and refreshing it later. Meta-frameworks use this to combine a fast first paint with up-to-date data.
Outside linkNext.js: Partial Prerendering Outside linkSvelteKit: rendering & SSR
Recommended: Hydration and islands
Server-rendered HTML does nothing until JavaScript hydrates it, and that cost is easy to overlook. Islands architecture ships JavaScript only for the parts of a page that need it.
Outside linkIslands architecture (Jason Miller) Outside linkAstro: islands
Recommended: React Server Components and streaming
Components that run only on the server and send no JavaScript to the browser, streamed as they become ready. The largest change to React's model in years.
Outside linkReact: Server Components Outside linkNext.js: Server Components
Core: Routing
Client-side routing, nested layouts, loading data per route, and file-based routes. Routing ties pages, data and code-splitting together.
Outside linkReact Router docs Outside linkNext.js: App Router
Stage 13
Performance and Core Web Vitals
Core Web Vitals turn "it feels slow" into three measurements, LCP, INP and CLS, that you can track and test for regressions. Profile to find the real bottleneck before changing anything, then set a budget so the page stays fast.
Core: Core Web Vitals
LCP measures loading, INP measures responsiveness and CLS measures visual stability. Google uses them as page experience signals in search.
Outside linkweb.dev: Web Vitals Outside linkweb.dev: learn Core Web Vitals
Core: Measuring with Lighthouse, DevTools and RUM
Lab tools such as Lighthouse and the Performance panel find problems; field data from real users (RUM, CrUX) shows which ones matter. You need both.
Outside linkChrome: Lighthouse Outside linkChrome: Performance panel
Core: Loading performance
Code-splitting, lazy loading, preload and prefetch, and a shorter critical path. Send less JavaScript, and send the most important parts first.
Outside linkweb.dev: reduce JS payloads (code-splitting) Outside linkweb.dev: tree-shaking
Recommended: Runtime performance
Layout, paint and compositing, long tasks, and keeping the main thread free so the page responds quickly. This is why animating
widthstutters and animatingtransformdoes not.Outside linkweb.dev: rendering performance Outside linkMDN: performance
Recommended: Bundle size
Audit what you ship, rely on tree-shaking, and check the cost of each import. One heavy date library can be larger than the rest of the app.
Stage 14
Accessibility
Accessibility is a basic requirement for users and, in many countries, a legal one. Most of it comes for free with semantic HTML and keyboard support. Adding ARIA to a page built from divs later costs far more, so treat it as part of building, not a final audit.
Core: WCAG
The four principles (perceivable, operable, understandable, robust) and the A, AA and AAA conformance levels. Most audits and accessibility laws refer to WCAG.
Outside linkW3C: WCAG overview Outside linkW3C: accessibility fundamentals
Core: Using ARIA correctly
Use native elements first, ARIA only to fill gaps, and follow the published patterns for widgets. Incorrect ARIA can make a page worse than having none.
Outside linkW3C: ARIA Authoring Practices Outside linkMDN: ARIA
Core: Keyboard and focus
Everything usable without a mouse, a visible focus indicator, a sensible tab order, and focus kept inside open modals. Keyboard problems are among the most common accessibility failures.
Outside linkWebAIM: keyboard accessibility Outside linkMDN: keyboard-navigable widgets
Recommended: Screen readers and testing
How content is announced, and testing with axe and with a real screen reader. Automated tools find only some of the problems, so manual testing is still needed.
Recommended: Colour and contrast
Contrast ratios, not using colour as the only signal, and respecting a user's reduced-motion setting. Cheap to get right and obvious when wrong.
Outside linkWebAIM: contrast checker Outside linkMDN: prefers-reduced-motion
Stage 15
Testing
Tests let you change code with confidence. On the frontend, test behaviour the way a user experiences it rather than implementation details, so a refactor that keeps the UI working also keeps the tests passing.
Core: What to test
The testing trophy: mostly integration and component tests that resemble real use, fewer unit tests, and a small number of end-to-end tests.
Outside linkTesting Library: guiding principles Outside linkKent C. Dodds: the testing trophy
Core: Unit testing
Vitest for Vite projects and Jest elsewhere. Fast, isolated tests for logic such as utilities, reducers and hooks.
Core: Component testing
Testing Library renders a component and finds elements the way a user would, by role and text rather than class name, so tests survive refactors.
Outside linkReact Testing Library Outside linkTesting Library: queries
Recommended: End-to-end testing
Playwright and Cypress drive a real browser through complete flows. These tests are the slowest and give the most confidence, so keep them for the most important paths.
Recommended: Mocking the network
Mock Service Worker intercepts requests at the network level, so tests and local development share one set of mocks instead of stubbing
fetchin every test.Outside linkMock Service Worker (MSW) Outside linkTesting Library: ecosystem
Stage 16
Frontend system design
Senior frontend interviews often ask you to design something, such as a news feed, an autocomplete, a design system or a collaborative editor, and to explain your choices on rendering, data flow, caching, accessibility and performance. This stage uses everything from the earlier ones.
Core: The frontend system design interview
Requirements, component structure, data model, API, rendering approach, then performance and accessibility. Following the same steps each time works better than improvising.
Outside linkGreatFrontEnd: system design Outside linkAwesome frontend system design
Core: Designing a component library
Component APIs, composition over configuration, theming, accessibility and versioning. A common prompt in senior frontend interviews.
Recommended: APIs from the client side
REST and GraphQL from the consumer's point of view, pagination, normalised caches and optimistic updates. The shape of the API affects the whole UI.
Outside linkGraphQL: learn SimulatorgRPC vs REST SimulatorJSON vs Protobuf
Recommended: Designing for failure
Rendering approach, where to split code, error boundaries, offline support and graceful degradation: how the frontend behaves when the network or the data does not.
Outside linkweb.dev: rendering on the web Outside linkPatterns.dev: rendering patterns
Core: Practice problems
Build real components under constraints: an autocomplete, an infinite feed, an image carousel, a dashboard. Repetition makes the framework second nature.
Outside linkGreatFrontEnd Outside linkBigFrontEnd.dev Outside linkFrontend Mentor
After this roadmap
- How it worksGuides to HTTP, DNS, HTTPS, CDNs and caching, the parts of the stack a page load depends on.
- SimulatorsModels of the HTTP request flow, the TCP handshake, caches and load balancers that run in the browser.
- CodexLonger study pages, including JavaScript and TypeScript in the languages section.