Frontend Developer Roadmap 2026

This roadmap is for anyone who wants to build websites and web apps and eventually be paid to do it: students, career changers, designers who want to ship their own work, and backend developers who have been avoiding CSS. It assumes only that you are comfortable using a computer.

It covers what a junior frontend developer is usually expected to know, in an order where each step makes the next one easier. Every step has a small project that proves you learned it and free, official resources to learn from.

Nobody can tell you exactly how long it will take. That depends on the hours you have each week, what you already know, and how much of your time goes into building rather than watching. Fast and slow are both normal; what matters is that each project gets finished.

How to use this roadmap

• Go in order, mostly. Starting the next step while you finish the previous project is fine; skipping JavaScript fundamentals to reach React sooner is not.
• Build the project before moving on. Reading and watching feel productive, but only building shows what you don't know yet. If you can build it without a tutorial, you have learned the step.
• Use official documentation first. MDN, web.dev and each tool's own docs are free and maintained. When a course disagrees with them, trust the docs.
• Keep everything on GitHub. From step 3 onwards, every project goes into a public repository. By the end, that history is most of your portfolio.

Set up your workspace

You need very little to start, and all of it is free:

• A code editor. Visual Studio Code is a common choice; any editor with syntax highlighting and a built-in terminal will do.
• Two browsers, such as Chrome and Firefox, so you notice when something works in only one. Learn the developer tools early: Elements for HTML and CSS, Console for errors, Network for requests. See the Chrome DevTools documentation; Firefox has equivalents.
• A terminal, for moving between folders (cd), listing files and running tools such as git and npm.
• Node.js, the LTS version from nodejs.org, which React, TypeScript and the testing tools run on.

A default setup is enough; don't spend a week on themes and extensions.

Once you can create a folder, open it in your editor and view an HTML file from it in the browser, you are ready for step one.

The roadmap

Steps 1 to 4 are the foundation, so take them in order. Steps 5 to 8 can overlap once you have a React project to apply them to. Step 9 runs alongside everything else.

1. HTML and CSS

   4–6 weeks

   Learn to structure content so browsers and assistive technology understand it, then lay it out on any screen size.

   • Semantic HTML: headings in order, landmarks such as header, nav and main, links versus buttons, and a proper label for every form field.
   • Accessibility basics from day one: keyboard navigation, visible focus styles, sufficient colour contrast and useful alt text.
   • CSS fundamentals: the cascade, specificity, the box model, units such as rem and %, and custom properties.
   • Layout with Flexbox and Grid, and responsive design with mobile-first styles and media queries.

   Prove it: a small multi-page site for a real or imaginary business, with a contact form. It should work on a phone and a desktop, and be fully usable with the keyboard alone.

   Learn from: MDN: Learn web development, web.dev: Learn CSS, web.dev: Learn Responsive Design

2. JavaScript fundamentals

   6–10 weeks

   The step most worth taking slowly. Frameworks come and go; the language underneath changes far less.

   • Variables, functions, arrays and objects, plus map, filter, find and reduce.
   • The DOM: selecting elements, handling events and updating the page.
   • Promises, async and await, and fetching data with fetch, including when the request fails.
   • Modules with import and export.
   • Reading error messages and stack traces, and debugging with breakpoints instead of guessing.

   Prove it: without libraries, build a to-do list or budget tracker that saves to localStorage, then a small app that fetches from a free public API and shows clear loading, empty and error states.

   Learn from: MDN: JavaScript Guide, web.dev: Learn JavaScript, MDN: Using the Fetch API

3. Git and GitHub

   1–2 weeks

   Version control is how teams share code, and GitHub is where people will look at your work.

   • The everyday loop: git status, git add, git commit, git log and git diff.
   • Branches, merging, and resolving a merge conflict calmly.
   • Pull requests, and a README that explains what a project does and how to run it.
   • A .gitignore, so dependencies, build output and secrets never get committed.

   Prove it: put your projects on GitHub with a README and screenshot each, and publish one with GitHub Pages. Make a change on a branch and merge it through a pull request, even as the only reviewer.

   Learn from: Git documentation, Pro Git book, GitHub Docs: Get started

4. A framework: React

   6–8 weeks

   Frameworks build interfaces from reusable components that stay in sync with your data. This roadmap defaults to React because it is widely used and well documented. Vue, Svelte and Angular are solid alternatives and the core ideas transfer, so if the jobs you want use one of them, learn that instead.

   • Components, props and state, and the UI as a result of the current state.
   • Lists with keys, conditional rendering and controlled forms.
   • Effects, and when you don't need one: most data transformation belongs in rendering, not in useEffect.
   • Loading data, with its loading and error states, and routing between pages.
   • Starting a project with a framework or a build tool such as Vite, as the React docs describe.

   Prove it: rebuild your API project from step 2 in React, then add a second page, a search or filter, and a form with validation messages.

   Learn from: React: Learn, Thinking in React, You Might Not Need an Effect

5. TypeScript

   2–4 weeks

   TypeScript adds types to JavaScript, so your editor catches many mistakes before the browser does. Many frontend codebases use it, so expect to meet it early.

   • Basic types, union types and optional properties.
   • type and interface, and typing function parameters and return values.
   • Narrowing: checking what a value is before using it, instead of silencing errors with as or any.
   • Typing React props, state and event handlers.
   • Types disappear at runtime, so API data still needs checking.

   Prove it: convert your React project to TypeScript with strict mode on, and remove every any.

   Learn from: TypeScript documentation, The TypeScript Handbook, React: Using TypeScript

6. Testing

   2–3 weeks

   Tests let you change code without breaking what already works.

   • Unit tests for plain functions such as formatting, validation and calculations.
   • Component tests that use the UI the way a person does: find the button by its label, click it, check what appears.
   • A few end-to-end tests that run the whole app in a real browser for the flows that matter most.
   • What makes a test useful: it fails when behaviour breaks and keeps passing when you refactor.

   The tools below are common choices; Jest and Cypress are established alternatives.

   Prove it: add unit tests for your helpers, component tests for your form and its validation errors, and one end-to-end test for the main flow. Run them on every push with GitHub Actions.

   Learn from: Vitest guide, React Testing Library, Playwright documentation

7. Accessibility and performance

   2–3 weeks

   You started on accessibility in step 1. Now learn to test accessibility and performance properly, and fix what you find.

   • Testing with a keyboard and a screen reader such as VoiceOver, NVDA or TalkBack.
   • Focus management in dialogs and after client-side navigation, when ARIA helps versus when native HTML already does the job, and the WCAG guidelines most teams work towards.
   • Core Web Vitals: Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift, and what usually hurts each.
   • Practical fixes: correctly sized images, lazy loading, reserved space for late content, and less JavaScript.
   • Lighthouse and the Performance panel, remembering that lab scores are not what real visitors experience.

   Prove it: audit your multi-page site and your React project, fix what you find, and record before-and-after results in each README.

   Learn from: web.dev: Learn Accessibility, web.dev: Learn Performance, web.dev: Web Vitals

8. Deployment

   1–2 weeks

   You have already published a static site; now deploy an app with a build step and keep it working.

   • What a production build produces, and how a static host serves it.
   • Environment variables, and why anything in frontend code is visible to every visitor: secret keys never belong there.
   • GitHub Pages, or platforms such as Netlify, Vercel and Cloudflare Pages that deploy from your repository and preview each pull request.
   • HTTPS, custom domains, and configuring client-side routes so a refresh doesn't return a 404.
   • Continuous integration: linting, type checks and tests on every pull request before merging.

   Prove it: deploy your React project from its repository, with a workflow that runs your checks on every pull request, and put the live link at the top of the README.

   Learn from: GitHub Pages documentation, Vite: Deploying a Static Site, GitHub Actions documentation

9. Building with AI coding tools, responsibly

   Ongoing

   AI coding assistants such as GitHub Copilot, Cursor, Claude Code and Codex are part of everyday frontend work. Use them as a tutor from the start, checking their explanations against the docs. Letting them write your project code before you understand the fundamentals skips the part where you learn.

   • Ask for explanations, reviews and alternatives, not only finished code.
   • Keep each change small, and read every line before you commit it.
   • Watch for new dependencies, deleted checks, and code that only handles the happy path.
   • Never paste secrets, credentials or other people's data into a prompt.
   • Be able to explain any code in your portfolio, whoever wrote the first draft.

   Prove it: build one feature with an AI assistant, then review the diff with the AI code review checklist before merging. In the pull request, note what you kept, changed and rejected.

   Learn from: How to review AI-generated code, The production checklist for vibe-coded applications, OWASP Top 10

Build a portfolio that gets interviews

A portfolio won't get you a job by itself, but a good one gives a reviewer reasons to talk to you. They may spend only a few minutes on it, so make the important things easy to find.

• Two or three strong projects beat ten tutorial clones. An app built alongside a video shows you can follow instructions; a project that solves a specific problem, with your own decisions, shows you can do the work.
• Pick problems you understand. A tool for a club, a local shop, a hobby or a previous job gives you real requirements and something genuine to talk about.
• Show quality, not just features. A live link, a README with screenshots, setup instructions, the main decisions and trade-offs, tests, and a note on accessibility and performance.
• Make it work everywhere. Check each project on a phone, with only a keyboard, and with network throttling in DevTools.
• Keep your commit history honest. Small commits with clear messages show how you work; one commit containing the finished project shows very little.
• Write up one project. The problem, what you tried, what went wrong and what you would change. It gives interviewers questions to ask and you answers already thought through.

Keep the portfolio site simple, with your projects and links to GitHub and your CV on the first screen. It is a frontend project too, so make it fast and accessible.

Common mistakes

• Tutorial loops. Finishing course after course without building anything alone. After each tutorial, build something similar without it.
• Starting with a framework. React on top of shaky JavaScript turns every bug into a mystery. If promises or the DOM still feel unfamiliar, go back to step 2.
• Collecting technologies. Learning three frameworks, two CSS libraries and a backend at once. Depth in one stack beats a long list of logos.
• Treating CSS as an afterthought. Many frontend bugs are layout bugs. Learn Flexbox, Grid and the cascade instead of adding !important until something works.
• Skipping accessibility. It is part of the job, and much cheaper to build in than to fix after launch.
• Copying code you can't explain. Whether it came from a forum, a tutorial or an AI assistant, code you don't understand is code you can't debug.

Most of these come from optimising for the feeling of progress rather than evidence of it. A finished, deployed and tested project is evidence.

One more mistake is waiting until you feel ready to apply, because that feeling may never arrive. Use the checklist below instead: once most of it is true, start applying and keep working through the rest.

Job-ready checklist

Tick an item only if you can do it without a tutorial open.

HTML, CSS and accessibility

• I can build a responsive layout from a design with Flexbox and Grid, without a CSS framework
• My pages use semantic HTML, labelled form fields and meaningful alt text
• Every project works with a keyboard alone, with visible focus
• I have tested a project with a screen reader and fixed what I found

JavaScript and TypeScript

• I can fetch data from an API and handle loading, empty and error states
• I can explain promises, async and await, and closures in my own words
• I debug with breakpoints and the Network panel, not only console.log
• I write TypeScript in strict mode without reaching for any

React, or your chosen framework

• I can build a multi-page app with components, state, forms and routing

• I know when an effect is needed and when it is not Workflow

• I use Git daily: branches, pull requests and merge conflicts

• My projects have tests that fail when behaviour breaks, running in CI

• I can deploy from a repository and handle environment variables safely

• I understand AI-generated code before committing it

Portfolio

• Two or three original projects, each deployed, with a README, screenshots and tests
• A portfolio site that is fast, accessible and works on a phone
• I can walk through any project's code and decisions in an interview

Frontend tools will keep changing. The fundamentals on this list change slowly, which is why they come first.