So you’ve been doing REST APIs for the past 5 years. Or perhaps you’ve been optimizing searches for your company’s gigantic database. Maybe writing the embedded software for a microwave oven? It’s been a while since you were rocking some Prototype.js to do proper OOP in the browser. And now you’ve decided it’s time to get up to speed with your frontend skills. You take a look at the landscape and it looks like this.
But you don’t have the time for that now. You’re in a giant maze, and you need a map. So I made a map.
A little disclaimer first: This is a cheat-sheet to get you up and running fast without having to make too many decisions by yourself. Basically I will be laying out a set of tools that just work together for general-purpose frontend development. This will get you comfortable with the environment and will save you a few headaches. Once you’re done with these topics, you’ll be confident enough to adjust the stack to your needs.
Structure of the map
I will divide the map into problems that you’ll need to tackle. For each problem, I will:
Describe the problem or the need for a tool
Decide which tool you will use to solve the problem
Explain why I chose that tool
Give a few alternatives
Problem: Need to organize your project and your dependencies.
Solution: NPM and Yarn
Reason: NPM is pretty much the de-facto package manager. Yarn runs on top of NPM but optimizes dependency resolution and keeps a lock file of the exact version of your libraries (use it in tandem with NPM’s semantic versioning, they’re not exclusive, they complement each other).
Alternatives: TypeScript, CoffeeScript, PureScript, Elm
Problem: Many browsers that are still massively in use don’t implement ES6. You need a program that translates (transpiles) your modern ES6 into equivalent, well-supported ES5.
Reason: Works perfectly and it’s pretty much the de-facto standard. Transpiles server-side.
Reason: Great code insight and very configurable. The airbnb preset is all you need to get up and running. Really helps you get used to the new syntax.
Problem: You are no longer using a flat file or sequence of files. Dependencies need to be resolved and loaded properly.
Reason: Highly configurable. Can load all sorts of dependencies and assets. It’s pluggable. It’s pretty much the de-facto bundler for React projects.
Disadvantages: Can be a little hard to configure at first.
Notes: You’ll want to spend some time really understanding how this guy works. You should also learn about babel-loader, style-loader, css-loader, file-loader, url-loader.
Problem: Your app is fragile. It will fall apart. You need tests.
Reason: Batteries included, snapshot testing, can detect tests affected by your changes and run only those, works nicely with monorepos, comes by default with CRA, backed by Facebook.
Alternatives: Jasmine, Mocha, Tape.
UI framework / state management
Problem: This is one of the big ones. SPAs have grown more and more complex. Mutable state is particularly troublesome.
Solution: React and Redux
Reasons for using Redux: If your app is non-trivial, you need a tool to manage the state (otherwise you’ll be doing gymnastics for your components to talk to each other, learn vanilla inter-component communication first to experience the limitations). Every tutorial on the web will walk you through the confusing, abstract Flux pattern and all implementations that there have ever been. Save yourself a decent amount of time and go straight to Redux. It implements the pattern in a very simple manner. Even Facebook uses this. Extra awesomeness: reload and keep application state, time travel, testability.
Alternatives: Angular2, Vue.js.
DOM manipulation and animations
Problem: Guess what? You’ll still need occasional quickfixes where you’ll have to target selectors and perform operations directly on DOM nodes.
Solution: Plain ES6 or jQuery.
Reason: Yes, jQuery is still alive and well. React and jQuery aren’t mutually exclusive. Although, be aware that you should be able to do most of what you need with vanilla React (and querySelector). Adding jQuery will also increase your bundle’s footprint slightly. I’d say that using jQuery on top of React is a smell and you should avoid it whenever possible. If you hit a certain corner case that you can’t figure out with just React + ES6 features, or if you’re dealing with some annoying cross-browser quirk, jQuery might save the day.
Alternatives: Dojo (does that still even exist?).
Problem: Now that you have proper modules, you want them to be self-contained, reusable pieces of software that you can move around. Component styles should be as portable as the components themselves.
Solution: CSS modules.
Reason: As much as I love inline styles (and use them extensively), I must admit that they’re rather limited. Yes, it’s totally OK to use inline styles in React, but you can’t target pseudo-class selectors (like :hover) with them, which is a deal-breaker in many cases.
Boilerplate projects like Create React App can lift some of the burden for the problems described above. When using a boilerplate, you still need to understand what’s going on under the hood — otherwise, you’ll never truly have ownership of your build.
You now have a metric shit-ton of stuff to study, but at least you won’t need to spend so much time doing research. Do you think I missed something? Did I drop the ball somewhere? Leave a comment or reach me on twitter @bug_factory.