Web development with React from scratch: the roadmap I use

Almost everyone who asks me for help with React arrives with the same problem: they have followed three tutorials on YouTube, copied a to-do app, and end up with a project that “works” but that they couldn’t redo on their own. They can write useState from memory, but if you ask them why the component re-renders they freeze. It is the same pattern I see with Python and with C: you learn to paste, not to reason.

React isn’t hard. It is hard to jump into it without foundations. Most of the frustration I see doesn’t come from React itself, but from the JavaScript underneath that nobody has ever sorted out. In this article I give you the roadmap I really use in lessons with people starting almost from zero: first the foundations are put right, then you enter React in an orderly way, and at the end you build a project that is yours and that you can explain.

Before React: what must already be there

This is the part tutorials skip, and it is the reason you then understand nothing. React is a JavaScript library. If your JavaScript is shaky, React will seem like black magic. Before writing the first component you need to be comfortable with four things.

1. The DOM and how to manipulate it by hand. You must have written at least one small page in “vanilla” HTML/CSS/JavaScript, where you select an element, listen for a click and change the content. It serves precisely to appreciate what React solves for you: once you have done document.querySelector and addEventListener by hand ten times, you will understand at once why React exists.
2. JavaScript ES6+. let/const (and why no longer var), arrow functions, destructuring, the spread operator (...), template literals. These aren’t stylistic details: React uses them everywhere, and if you don’t recognise them the code looks written in another language.
3. Array methods: map, filter, reduce. In React a list of elements is almost always built with .map(). If map isn’t clear to you, rendering lists will seem incomprehensible.
4. Asynchronicity: Promises, async/await, and fetch to call an API. Every real app sooner or later loads data from a server, and there asynchronicity is unavoidable.

If while reading this list you felt a gap, the advice is brutal but true: stop and close it before touching React. An afternoon on destructuring saves you two weeks of confusion afterwards.

Weeks 1-2: JavaScript foundations

For the first two weeks you don’t touch React. I know it is frustrating, but it is the investment that makes the difference between those who then fly and those who stay stuck in the mud.

Concrete exercises I assign:

• Rewrite a small static site (one page) by manipulating the DOM: a counter with two buttons, a list to which you add items from an input, a light/dark theme with a toggle.
• Take an array of objects (for example a list of students with name and grade) and with map/filter/reduce calculate the average, filter those above the pass mark, build a new list of just “Name: grade” strings.
• Make a fetch call to a free public API, handle the response with async/await and print a piece of it on the page.

The aim isn’t beautiful code, it is fluency. When these movements become automatic, React stops being intimidating.

Week 3: the first component and JSX

Now you go in. The central concept of React is just one: the interface is a function of state. You describe how the page must look given certain data, and React takes care of updating the DOM when that data changes. You no longer touch the DOM by hand: this is the liberation you earned by doing it by hand in the first weeks.

The building blocks of week 3:

• Components: JavaScript functions that return JSX. A component is a reusable piece of interface (a button, a card, a form).
• JSX: that syntax that looks like HTML inside JavaScript. It isn’t HTML, it is syntactic sugar that turns into function calls. Understanding this avoids half of beginners’ mistakes (for example why you write className and not class).
• Props: how a component receives data from its parent. They are read-only: a component never modifies the props it receives.

Exercise for the week: break a page into components. Take the site you made in vanilla in week 1 and rebuild it as a tree of React components, still without interactivity. Only structure and props.

Week 4: state and hooks

Here comes the heart of modern React, and it is the point where those who skipped the foundations collapse. State is the data that changes over time and makes the interface redraw.

• useState: declares a state variable. When you update it with the function it returns, React re-renders the component. The point almost everyone gets wrong: state in React is immutable. You don’t modify the existing array, you create a new one (that is why the spread operator from week 1 mattered).
• useEffect: you run code as a side effect (typically an API call) after the render. It is the most misunderstood hook: it is for synchronising the component with something external (a server, a timer, localStorage), not for every bit of logic that comes to mind.
• The render: understand when and why a component re-renders. If you can answer this question, you have understood React. If you can’t, you are guessing.

Exercise: add interactivity to the week 3 project. A controlled form (the input is tied to state), a list that grows, data loaded from an API inside useEffect with loading and error handling.

Week 5: putting together a real app

Now you move from “exercises” to “application”. The topics I add:

• Lifting state up: when two components need to share a piece of data, the state lives in their common parent. Understanding this avoids duplicating data that then goes out of sync.
• Conditional rendering and lists with key: showing or hiding pieces of UI, and giving each element of a list a stable key (not the array index, if the list changes order).
• A minimum of routing, if you need to navigate between several pages.

You don’t need to overdo the libraries. One of the most common mistakes is throwing yourself at Redux, Next.js and a thousand dependencies before having understood local state. As I always say: fundamentals first, then tools.

Week 6: the project that stays

As with the Python roadmap, the final week is dedicated to a project of your own, a concrete one, chosen by you. Examples I have followed with students:

• An app to track study hours with a weekly chart.
• A small flashcard manager for revision (useful for those preparing an admission test).
• A weather app that pulls data from a public API.
• A dashboard that displays and filters a list of data loaded from a JSON file.

The project is the part that stays in your hands and that you discuss at an exam or show in an interview. The six weeks of exercises serve to arrive here with solid foundations, not to produce code to throw away.

The mistakes I see most often

After many lessons on React, the stumbles are almost always the same:

• Starting React without JavaScript. Number one. If destructuring and map aren’t automatic, React will seem incomprehensible and you will blame React.
• Mutating state directly. Doing array.push(...) and expecting the re-render. It doesn’t happen: you have to create a new array. The most insidious bugs for a beginner come from here.
• Overusing useEffect. Putting in it logic that isn’t a side effect, or forgetting the dependency array and creating infinite loops.
• Copying without rebuilding. It holds for React even more than elsewhere: if you take a component from a tutorial or from an AI assistant, rewrite it line by line until you could redo it with your eyes closed.
• Frameworks too soon. Next.js, TypeScript, state libraries: all useful, none in the first month. First local state and components, then the rest.

How long it really takes

With a decent JavaScript base, six weeks of consistent work will get you building a small but complete React app on your own. If you start from the DOM and ES6+, add two more weeks for the foundations, and don’t consider it lost time, it is the opposite. The “three days to become a React developer” timelines that circulate online are marketing: you get there, but not in three days and not by copying.

How we work in lessons

When I follow someone on React I don’t write the project in their place. We work together: I correct the exercises, explain to you why one component re-renders and another doesn’t, we debug the errors together (React’s message almost always tells you where to look), and we structure the architecture of the app. That way, when you discuss it at the exam or show it to someone, you know exactly what you did and why.

The same approach applies that I use for all computer science: MATLAB, Python, C and web development. The aim isn’t to get you to finish the project, it is to make you independent.

If the basics of the page are still uncertain, start from HTML and CSS.

If you want to follow this roadmap with someone who corrects your exercises and helps you build the final project, book a free 30-minute introductory call: we work out your starting level together and build a path that suits the time you have.