Who Is This For
This study plan is for you if:
- You’re already familiar with basic programming concepts like variables and functions.
- You might have already done back-end work with languages such as PHP and Python, and maybe used front-end libraries such as jQuery for a few simple hacks.
- You now want to get into more serious front-end development but are drowning in frameworks and libraries before you’ve even started.
Things We’ll Cover
- Why you can’t just use jQuery
- Why React is the safest pick
- How to learn ES6 syntax
- Why and how to learn Redux
- What GraphQL is and why it’s a big deal
- Where to go next
Resources Mentioned Here
Disclaimer: this post will include a few affiliate links to courses by Wes Bos, but the material is recommended because I genuinely think it’s good, and not just because of the affiliate scheme.
If you would rather find other resources, Mark Erikson maintains a great list of React, ES6, and Redux links.
For starters, let’s look at a “traditional” web app circa 2008:
- The database sends data to your back-end (e.g. your PHP or Rails app).
- The back-end reads that data and outputs HTML.
- The HTML is sent to the browser, which displays it as the DOM (basically, a web page)
Now compare this with a “modern” 2016 web app (also known as the “Single Page App”):
Notice the difference? Instead of sending HTML, the server now sends data, and the “data to HTML” conversion step happens on the client instead (which is why you’re also sending along the code that tells the client how to perform said conversion).
This has many implications. First, the good:
- For a given piece of content, sending only data is faster than sending entire HTML pages.
- The client can swap in content instantly without having to ever refresh the browser window (thus the term “Single Page App”).
- The initial load takes longer since the “data to HTML” codebase can grow quite large.
- You now need a place to store and manage the data on the client too, in case you want to cache it or inspect it.
And the ugly:
- Congratulations — you now have to deal with a client-side stack, which can get just as complex as your server-side stack.
The Client-Server Spectrum
So why go through all this trouble if there are so many downsides? Why not just stick to the good old PHP apps of old?
Well, imagine you’re building a calculator. If the user wants to know what 2 + 2 is, it doesn’t make sense to go all the way back to the server to perform the operation when the browser is perfectly capable of doing it.
On the other hand, if you’re building a purely static site such as a blog, it’s perfectly fine to generate the final HTML on the server and be done with it.
The truth is, most web apps fall somewhere in the middle of the spectrum. The problem is knowing where.
But the key thing is that the spectrum is not continuous: you can’t start with a pure server-side app and slowly move towards a pure client-side app. At some point (the Divide), you’ll be forced to stop and refactor everything, or else end up with a mess of unmaintainable spaghetti code.
This is why you shouldn’t “just use jQuery” for everything. You can think of jQuery like duct tape. It’s amazingly handy for small fixes around the house, but if you keep adding more and more things will start looking ugly.
Week 1: Start With React
I believe the answer is React.
React is a UI library created and open-sourced by Facebook. In other words, it takes care of that “data to HTML” step (the View Layer).
Now don’t get me wrong: I’m not telling you to pick React because it’s the best library out there (because that’s highly subjective), but because it’s pretty good.
- React might not be the most popular library, but it’s pretty popular.
- React might not be the most lightweight library, but it’s pretty lightweight.
- React might not be the easiest to learn, but it’s pretty easy to learn.
- React might not be the most elegant library, but it’s pretty elegant.
In other words, React might not be the best choice in every situation, but I believe it’s the safest. And believe me, “just when you’re starting out” is not the right time to take risks with your technological choices.
React will also introduce you to some useful concepts like components, application state, and stateless functions that will prove useful no matter which framework or libraries you end up using during your career.
Finally, React has a large ecosystem of other packages and libraries that work well with it. And its sheer popularity means you’ll be able to find a lot of help on sites like Stack Overflow.
I personally recommend the React for Beginners course by Wes Bos. It’s how I learned React myself, and it’s just been completely overhauled with the latest React best practices.
But for others, this feels like learning to swim by studying human anatomy and fluid dynamics. Sure, they both play a huge role in swimming, but it’s more fun to just jump in the pool!
Week 2: Your First React Project
Let’s assume you’ve just completed a React course. If you’re like me, two things are probably true:
- You’ve already forgotten half of what you just learned.
- You can’t wait to put the half you do remember in practice.
I believe the best way to learn a framework or a language is to just use it. And personal projects are the perfect occasion to try out new technologies.
A personal project could be anything from a single page to a complex web app, but I feel like redesigning your own personal site can be a good middle ground. Plus, I know you’ve probably been putting it off for years!
Now I did say earlier that using single-page apps for static content was often overkill, but React actually has a secret weapon: Gatsby, a React static site generator that lets you “cheat” and get all the benefits of React without any of the downsides.
Here’s why Gatsby is a great way to get started with React:
- A pre-configured Webpack, meaning you get all the benefits without any of the headaches.
- Automatic routing based on your directory structure.
- All HTML content is also generated server-side, so you get the best of both worlds.
- Static content means no server and super-easy hosting on GitHub Pages.
Week 3: Mastering ES6
In my own quest to learn React, I soon reached a point where I could get by copy-pasting code samples, but there was still a lot I didn’t understand.
Specifically, I was unfamiliar with all the new features introduced by ES6, such as:
- Arrow functions
- Object destructuring
- The spread operator
If you’re in the same boat, it might be time to take a couple days and learn ES6 properly. If you enjoyed the React for Beginners course, you might want to check out Wes’ excellent ES6 for Everybody videos.
Or if you prefer free resources, check out Nicolas Bevacqua’s book, Practical ES6.
A good exercise for mastering ES6 is going through an older codebase (such as the one you just created in Week 2!) and converting your code to ES6’s shorter, terser syntax whenever possible.
Week 4: Taking On State Management
As this point you should be capable of building a simple React front-end backed by static content.
But real web apps are not static: they need to get their data from somewhere, generally a database of some kind.
Now you could just send data to your individual components, but that quickly gets messy. For example, what if two components need to display the same piece of data? Or need to talk to each other?
This is where State Management comes in. Instead of storing your state (in other words, your data) bit by bit in each component, you store it in a single global store that then dispatches it to your React components:
In the React world, the most popular state management library is Redux. Redux not only helps centralize your data, but it also enforces some strict protocols for manipulating this data.
You can think of Redux as a bank: you can’t go to your local branch and manually modify your account total (“here, let me just add a couple extra zeroes!”). Instead, you fill out a deposit form, then give it to a bank teller authorized to perform the action.
Similarly, Redux also won’t let you modify your global state directly. Instead, you pass actions to reducers, special functions that perform the operation and return the new, updated state as a result.
The result of all this extra work is a highly standardized and maintainable data flow throughout your app, and access to tools such as the Redux Devtools to help you visualize it:
Once again you can stay with our friend Wes and learn Redux with his Redux course, which is actually completely free!
Or, you can check out Redux creator Dan Abramov’s video series on egghead.io, which is free as well.
Bonus Week 5: Building APIs With GraphQL
So far we’ve pretty much only talked about the client, and that’s only half the equation. And even without going into the whole Node ecosystem, it’s important to address one key aspect of any web app: how data gets from the server to the client.
It won’t come as a surprise that this, too, is rapidly changing, with GraphQL (yet another Facebook open-source project) emerging as a serious alternative to the traditional REST APIs.
Whereas a REST API exposes multiple REST routes that each give you access to a predefined dataset (say, /api/posts, /api/comments, etc.), GraphQL exposes a single endpoint that lets the client query for the data it needs.
Think of it as making multiple trips to the butcher shop, bakery, and grocery store, versus giving someone a shopping list and sending them on their way to all three.
This new strategy becomes especially significant when you need to query multiple data sources. Just like with our shopping list example, you can now get data back from all these sources with a single request.
GraphQL has been picking up steam over the past year or so, with many projects (such Gatsby, which we used in Week 2) planning on adopting it.
GraphQL itself is just a protocol, but its best implementation right now is probably the Apollo library, which works well with Redux. There is still a lack of instructional material around GraphQL and Apollo, but hopefully the Apollo documentation can help you get started.
Beyond React & Co
I recommended you start with the React ecosystem because it’s a safe pick, but it’s by no means the only valid front-end stack. If you want to keep exploring, here are two recommendations:
Vue is a relatively new library but it’s growing at record speeds and has already been adopted by major companies, especially in China where it’s being used by the likes of Baidu and Alibaba (think Chinese Google and Chinese Amazon). And it’s also the official front-end layer of PHP framework Laravel.
Compared to React, some of its key selling points are:
- Officially-maintained routing and state management libraries.
- Focus on performance.
- Lower learning curve thanks to using HTML-based templates.
- Less boilerplate code.
As it stands, the two main things that still give React an edge over Vue are the size of the React ecosystem, and React Native (more on this later). But I wouldn’t be surprised to see Vue catch up soon!
This brings multiple advantages, such as improved performance, enforced semantic versioning, and no runtime exceptions.
By now you should have a pretty good grasp of the entire React front-end stack, and hopefully be reasonably productive with it.
- Build tools (Webpack…)
- Type systems (TypeScript, Flow…)
I can’t cover all this here but don’t despair! The first step is always the hardest, and guess what: you’ve just taken it by reading this study plan.
And now that you understand how the various pieces of the ecosystem fit together, it’s just a matter of lining up what you want to learn next and knocking down a new technology each month.
Keep In Touch