What you need to know before React: check yourself against the list

August 28, 2026 · 8 minutes · Dediu Pavel

The advice «learn JavaScript first» is useless without a criterion for «enough». Below is a concrete list: what you need in hand before React, what you can do without, and in what order to go on.

The short answer: why «React without markup» does not exist

React does not replace HTML and CSS, it produces them. A component is a function that returns a description of markup; the same tags and the same classes end up in the browser. If you do not understand why a block moved, you will not understand it in React either — only now there will be a bundler between you and the markup as well.

Second: React does not solve layout problems. Inside a component you still need flex and grid, button states, focus order, behaviour on a narrow screen. No hook does any of that.

How this looks in practice: someone without the basics gets stuck not on React but on the language — and does not realise it. The error «Rendered fewer hooks than expected» reads as a problem with the framework, while it means an early return above a hook call. An infinite render looks like React being capricious, while in reality it is an object created in the component body that ended up in the dependencies. Without the basics such things are debugged by guesswork; with them, in a minute.

And the third, the most unpleasant for anyone hoping to skip ahead: without basic JavaScript, React looks like a set of incantations. Arrays, objects, references, promises are not an «addition» but the material every component is made of. Someone who does not understand the difference between a copy of an object and a reference to it will spend weeks chasing the bug «I changed the state and the screen stayed the same».

What of HTML and CSS is required, and why exactly that

The list is shorter than it seems, and every item on it pays off immediately.

Semantic tags. You need to be able to choose between section, article, button and div. In React the temptation to build everything out of a div with a click handler is especially strong, while a real button gives you keyboard focus and firing on Enter for free.

The box model and the flow. Why a block ended up exactly that size, what box-sizing: border-box does, where a horizontal scrollbar comes from. These are exactly the same questions as without React, but debugging them inside a component tree is harder. If the topic feels shaky, start with the piece on why a block is wider than you set.

Flexbox and Grid. Not the properties by heart, but the ability to choose: a row or a table, and who distributes the free space. In React the catalogue markup lives in a CSS file and does not go anywhere.

States and a minimum of accessibility. :hover, :focus-visible, disabled, a visible focus ring, tying a label to its field. Forms are the second largest module of any React project, and all of that is needed there straight away.

The criterion «I know markup» is best stated not through a list of topics but through a result: you take someone else's design and reproduce it without nudging things by eye, and to the question «why is this block that wide» you answer with a calculation rather than a shrug. If that is still far off, React will speed nothing up.

What you can do without: animation, preprocessors, CSS-in-JS, the finer points of fonts. Those are picked up later, in an evening.

What of JavaScript is needed: destructuring, map, promises, async/await, modules

Also not «the whole language». You need the set that shows up in every other component.

Destructuring. Writing function Card({ product }) is exactly that, and props are painful to read without it. Plus array destructuring: const [value, setValue] = useState(1) is ordinary array destructuring, not hook magic.

Array methods. map for rendering a list, filter for a catalogue filter, find, some, reduce for a cart total. The key point is that they return a new array and do not change the original.

Copying with spread. { ...order, qty: 2 } and [...items, product]. In React, state is only updated with a new value: push and assigning to a field change the object in place, the reference stays the same, React compares with Object.is, sees a match and skips the render.

Functions and closures. Arrow functions, a function as an argument, and understanding that a function created in the component body is a new one every time. Without that it is impossible to make sense of effect dependencies.

Promises, async/await and fetch. A request to a server, waiting for the answer, handling an error. Plus try/catch and JSON.parse.

Modules. import and export, and the difference between a default and a named export. A React project is two or three dozen files tied together by imports.

What of JavaScript you can do without before you start: prototypes and this, classes, generators, working with dates, regular expressions, the finer points of the event loop. That does not mean they are never needed — it means you will not need them once before your first component.

Expressions versus statements. The ternary operator and && instead of if inside markup. That is not a matter of style: a value is substituted into markup, and if has no value.

A self-check list: seven tasks you should be able to solve

The criterion is simple: you do each task yourself, without a ready solution in front of you, and can explain every line. The time for all seven is one evening.

• Build a row of cards that rearranges into a single column on a narrow screen, and explain why flex or grid was chosen.
• Find the cause of a horizontal scrollbar in someone else's page and fix it without hunting for percentages.
• Write a function that takes an array of products and returns a new array with only the products under 30, sorted by price; the original array is unchanged after the call.
• Get a copy of an object with one field changed, and explain how that differs from order.qty++.
• Load data from any open API with fetch and async/await, render the list, show an error message when the network drops and an indicator while it is loading — in plain JavaScript, without libraries.
• Attach an event handler to document, remove it, and explain why it must be removed.
• Split the code across two files, export a function from one and import it into the other, and run that in the browser.

What to do with the result of the checklist

Check yourself honestly: without a ready solution in the next tab, without a hint from a neural network, on the first try. A task counts as solved if you can say out loud why every line in it is there, and fix it when it breaks. Otherwise it is not a skill but recognition.

Passed all seven — you can start React, and the coming months will go on learning to think in state rather than on fighting the language.

Stuck on the first two — you need markup, not React: «Markup without magic» covers the flow, the box model, flex, grid, responsiveness and forms. That is not «a step back» but the short road: those topics have to be worked through anyway, only inside React they cost more.

Got through the markup but stumbled on tasks three to seven — pick up JavaScript point by point from the list above, rather than «the whole language from the beginning».

If the checklist is passed in full, the «React in practice» course fits next — 26 hours, and its entry requirement says exactly that: markup needed. It starts with setting up a project on Vite and splitting the catalogue design into components, and ends with a shop with a cart, checkout and deployment — that is, with the tasks React is taken up for in the first place.

What you do NOT need to know (and where beginners lose months for nothing)

TypeScript. Useful, but it adds a second language on top of an unfamiliar first one. Take it after two or three projects in JavaScript.

Redux and other state managers. In modern React their place is taken by useState, context and useReducer; an external store makes sense once you have felt with your own hands what is missing.

Next.js and server rendering. A separate tool with rules of its own. Learning it instead of React is a guaranteed mess.

Class components and lifecycle methods. They remain in old code, and they are not a topic for getting started.

Configuring webpack and Babel. Vite builds with a single command. Configuring a bundler is a task that will come up in a year, if at all.

Algorithms and interview puzzles. They have nothing to do with the ability to build an interface.

Testing, patterns, architecture. All of that settles onto experience. On empty ground they turn into rules without reasons.

Why it is a bad idea to start by copying a big project from YouTube

A ten-hour video «building a marketplace in React» gives a feeling of progress and almost zero skill. The reason is mechanical: you repeat a set of characters while the author makes the decisions. At the end you have a working project and not a single bug you found yourself — and finding bugs is the main work.

You can check yourself like this: pause the video before a change and predict what will happen on screen. Right — you understand the material. Wrong — you are watching a film.

The second sign of the same thing: after the video you can repeat the project but cannot add a new feature that was not in it. Add sorting by price to someone else's catalogue, and it becomes clear where the copy ends and understanding begins.

A working replacement: small tasks you formulate yourself, plus deliberate breakage. Built a quantity counter — break it: add two by calling the setter twice in a row and see why only one is added. Wrote an effect with a subscription — remove the cleanup function and see how, after opening the modal five times, Escape fires five times. Such breakages stick better than any explanation, because you see cause and effect yourself.

The order of topics inside React itself

The sequence in which the topics do not get in each other's way looks like this: setting up the project and JSX; components and props; state with useState; lists, keys and conditional rendering; forms and validation; effects and loading data from a server; loading and error states; routing; shared state — context and useReducer; performance and unnecessary renders; tests; build and deployment.

Two places where almost everyone stumbles. The first is useEffect: people take it as «do something after the render» and start calculating derived data in it. A filtered list and an order total are calculated right in the component body, while an effect is for synchronising with the outside world — the tab title, a keyboard listener, a timer, a request.

The second is effect dependencies. React compares them with Object.is: primitives by value, and objects, arrays and functions by reference. An object created right in the component body is new on every render, the comparison fails, and the effect runs again and again. Most infinite loops grow from this, and the understanding of references from the checklist pays off exactly here.

As for timing, the rough guide is this: if your markup is already confident, the first independent application with data and routes is about two or three months of regular study away. Promises of «React in two weeks» usually mean that markup and JavaScript are not included in that period.

One thing worth knowing in advance: in development mode React mounts a component twice, so an effect runs twice. That is not a bug and not a reason to remove StrictMode — it is a check that your effect cleans up after itself properly.

React, Vue or something else: the short honest answer

For a beginner the difference between them is smaller than the difference between «I know markup» and «I do not». Components, props, state, lists with keys, effects — they are everywhere, and a second framework after the first takes a couple of weeks.

There is one practical criterion: look at a dozen job ads you would actually apply to and take whichever appears more often there. It is usually React, but in your city or your niche it may be otherwise.

The same answer goes for «the fashionable stack». Vue, Svelte, Solid and Angular change the syntax and the set of conventions, but they do not change the tasks: split an interface into parts, keep state in one place, show loading and errors, do not break the layout on a narrow screen. All of that transfers between tools almost without loss, whereas gaps in markup and the language transfer nowhere.

And do not switch until you have taken two or three of your own projects to the end. Changing tools almost always moves the moment when things get hard rather than removing it: it will get hard in exactly the same place — on state, on server data and on edge cases.