Is React hard to learn? Is React easy to learn? Well, it depends on your approach.
This here is your timeline for learning React. Think of these steps as layers in a foundation.
If you were building a house, would you skip some steps to get it done faster? Maybe jump right to pouring the concrete before laying some rocks down? Start building the walls on bare earth?
Or how about making a wedding cake: the top part looks the most fun to decorate, so why not start there! Just figure out the bottom part later.
Of course not. You know those things would lead to failure.
So why does the standard approach to learning React involve trying to learn ES6 + Webpack + Babel + Redux + Routing + AJAX + React all at once? Sounds like a surefire path to overwhelm (and giving up)!
So I’ve laid out a timeline. Take these one step at a time. Do not skip steps. Do not learn 2 steps at the same time.
So How Long Does it Take To Learn React?
Taking this approach – one foot in front of the other, setting aside a bit of time each day – this is probably a few weeks of learning. If you don’t know JS very well, then it’s probably closer to a few months. If you do know JS decently well already, then you can be productive with pure React in probably just a week.
The theme of this strategy is to avoid getting overwhelmed. Slow and steady, uh, learns the React ;)
I’m a big believer in giving yourself tiny wins along the way. It makes the process more fun, and makes the learning go faster, too. So whichever step you’re on, try to do the minimally viable thing or scope down the requirements to get yourself a little win. Celebrate it. Then crank up the difficulty level and do it again.
You’ll want to have a good handle on things like…
thisworks (particularly how the current scope affects the value of
- function scope vs block scope
- control structures like
- how to write and call functions
- how to create and access objects and arrays
- functional features, especially
That’s not an exhaustive list but I think if you can do those things, you can start playing with React in small experimental apps. I’d highly recommend against trying to build a complicated piece of software (like that SaaS app you’ve been dreaming of) as your first outing. Big apps are bad learning projects. Get a few tiny apps (e.g. a few hours, a day, a weekend) under your belt first.
With prior programming experience, JS probably won’t take you too long to pick up. It has some quirks – scoping of
this is particularly quirky – but it’s a C-like language so if you’re used to one of those you should be all set.
Here is a good series of books called You Don’t Know JS. They’re free to read online.
The latest versions of React have phased out their usage of ES5 and the old
createClass way of making components – it’s all ES6 classes now. But outside of those, there isn’t too much ES6-specific syntax that’s absolutely required. Learn it as you go.
Step 0.5: NPM (or Yarn)
In order to use React and friends, you’ll need a package manager.
npm install <package name>).
Yarn is a more recent package manager and gives some nice improvements over NPM, chief of which is speed of installation. I use Yarn almost exclusively for that reason.
Every package is available through NPM or with Yarn – there are no exclusivity contracts here ;) So try both and pick your favorite.
Step 1: React
Try out the Hello World in 3 minutes tutorial!
Step 2: Build a Few Things, and Throw Them Away
This is the awkward middle step that a lot of people skip.
Don’t make that mistake. Moving forward without having a firm grasp of React’s concepts will lead straight back to overwhelmsville.
But this step isn’t very well-defined: what should you build? A prototype for work? Maybe a fancy Facebook clone, something meaty to really get used to the whole stack?
Well, no, not those things. They’re either loaded with baggage or too large for a learning project.
“Prototypes” for work are especially terrible, because you absolutely know in your heart that a “prototype” will be nothing of the sort. It will live long beyond the prototype phase, morph into shipping software, and never be thrown away or rewritten.
Using a work “prototype” as a learning project is problematic because you’re likely to get all worked up about the future. Because you know it’ll be more than just a prototype, you start to worry – shouldn’t it have tests? I should make sure the architecture will scale… Am I going to have to refactor this mess later? And shouldn’t it have tests?
This specific problem is what I cover in Pure React: once you get past “Hello World,” how do you learn to “think in React?”
Here’s the gist: the ideal projects are somewhere between “Hello World” and “All of Twitter.”
Take some existing large UIs (Twitter, Reddit, Hacker News, etc) and break off a small chunk to build – carve it up into components, build the pieces, and render it with static data. “Copywork” is the practice of recreating existing apps as a way of improving your skills and copywork is a great way to learn React.
You get the idea: small, throwaway apps. They must be throwaways otherwise you’ll get hung up on maintainability and architecture and other crap that just doesn’t matter yet.
I wrote Pure React to teach this way because there’s not much else out there that takes the bite-size approach.
React is Hard
Before you go too much further I just want to be straight with you. Learning React is gonna be tough. You will struggle at first, and that is TOTALLY NORMAL. The only way out is through: keep building tiny things until the concepts sink in.
Practice is super important. Building apps, even (especially) tiny ones is super important. Don’t just read tutorials and watch videos. Learning React (or anything, really) is not a linear process. It does not go like this:
- read/watch tutorials until it makes sense
- build a great app
The fastest path is (counterintuitively) more like this:
- read/watch just one tutorial
- try out what you just learned
- make some mistakes, re-read, fix them, try again
- try it on your own again
- success! tiny win! back to step 1.
So keep that in mind as you’re working through this stuff. It’s hard. It will get easier, but it will suck for a while, and you’re not stupid or foolish for struggling. Everybody struggles! “Programming is suffering.” At least I think that was the quote.
Step 3: Webpack
Build tools are a major stumbling block. Setting up Webpack feels like stumbling through a dark cave the first few times, and it’s a whole different mindset from writing UI code. This is why Webpack is down at Step 3, instead of Step 0.
I recommend Webpack – The Confusing Parts as an introduction to Webpack and its way of thinking.
Once you understand what it does (bundles every kind of file, not just JS) – and how it works (loaders for each file type), the Webpack part of your life will be much happier.
On the other hand, you can just avoid it by sticking with Create React App. It’s an awesome tool for development, and it’s even well-suited to build and deploy your React app to production.
Step 4: ES6
Now that you’re in Step 4, you have all those steps above as context. The bits of ES6 you learn now will help you write cleaner, better code – and faster. If you tried to memorize it all in the beginning, it wouldn’t have stuck – but now, you know how it all fits in.
Learn the parts you’ll use most: arrow functions, let/const, classes, destructuring, and
Step 5: Routing
Some people conflate React Router and Redux in their head – they’re not related or dependent on each other. You can (and should!) learn to use React Router before diving into Redux.
By this point you’ll have a solid foundation in “thinking in React,” and React Router’s component-based approach will make more sense than if you’d tackled it on Day 1.
Step 6: Redux
Dan Abramov, the creator of Redux, will tell you not to add Redux too early, and for good reason – it’s a dose of complexity that can be disastrous early on.
The concepts behind Redux are simple in isolation. But there is a mental leap from understanding the pieces to knowing how to use them in an app.
So, repeat what you did in Step 2: build disposable apps. Build a bunch of little Redux experiements to really internalize how it works.
There are a few bits of “common wisdom” that will torpedo your progress pretty quickly. Boilerplate projects, for one.
Diving into React by picking one of the bajillion boilerplate projects out there will only confuse you. They include every possible library, and force a directory structure upon you – and neither of these are required for smaller apps, or when you’re getting started.
It seems logical to start with a solid foundation in the form of a boilerplate that enforces best practices – but it’s a ton of complexity right up front that will make React & the related libraries harder to learn than if you tackled them one-by-one.
And if you’re thinking “But Dave I’m not building a small app, I’m building a complex app that will serve millions of users!”… go re-read that bit about prototypes ;)
How to tackle this
This is a lot to take in. It’s a lot to learn – but there’s a logical progression. One foot in front of the other.
Remember: it’ll be tough at first. Everybody struggles with this. Frontend development is complicated. But you can work through it! Tiny apps. Tiny wins. Lots of practice. It will all add up to understanding the entire stack and being able to build whatever you can imagine.
This article has been translated to: