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.

Of course you’re not looking for Waldo. You’re looking for 25 random guys and don’t even know what their names are. This feeling of being overwhelmed is so common in the JavaScript community that the term “JavaScript fatigue” actually exists. When you have time for some comedy about the subject, this post reflects the phenomenon brilliantly.

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

Package management

Problem: Need to organize your project and your dependencies.

Need to organize your project and your dependencies. Solution: NPM and Yarn

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).

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: None that I know of.

JavaScript flavor

Problem: ECMAScript 5 (aka old-school JavaScript) sucks.

ECMAScript 5 (aka old-school JavaScript) sucks. Solution: ES6

ES6 Reason: It’s the future JavaScript but you can use it right now. Incorporates many useful features that have been available to other programming languages for a long time. Interesting new features: arrow functions, module import/export capabilities, de-structuring, template strings, let and const, generators, promises. If you’re a Python coder you’ll feel at home.

It’s the future JavaScript but you can use it right now. Incorporates many useful features that have been available to other programming languages for a long time. Interesting new features: arrow functions, module import/export capabilities, de-structuring, template strings, let and const, generators, promises. If you’re a Python coder you’ll feel at home. Alternatives: TypeScript, CoffeeScript, PureScript, Elm

Transpiling

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.

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. Solution: babel

babel Reason: Works perfectly and it’s pretty much the de-facto standard. Transpiles server-side.

Works perfectly and it’s pretty much the de-facto standard. Transpiles server-side. Alternatives: Traceur

Traceur Notes: You will use babel-loader, a Webpack loader (more on that later on). You’ll need transpiling if you plan to use any of the other JavaScript flavors as well.

Linting

Problem: There’s a zillion ways of writing JavaScript and consistency is hard to achieve. Some bugs can be prevented with a linter.

There’s a zillion ways of writing JavaScript and consistency is hard to achieve. Some bugs can be prevented with a linter. Solution: ESLint

ESLint 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.

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. Alternatives: JSLint

Bundling

Problem: You are no longer using a flat file or sequence of files. Dependencies need to be resolved and loaded properly.

You are no longer using a flat file or sequence of files. Dependencies need to be resolved and loaded properly. Solution: Webpack

Webpack 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.

Highly configurable. Can load all sorts of dependencies and assets. It’s pluggable. It’s pretty much the de-facto bundler for React projects. Alternatives: Browserify

Browserify Disadvantages: Can be a little hard to configure at first.

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.

Testing

Problem: Your app is fragile. It will fall apart. You need tests.

Your app is fragile. It will fall apart. You need tests. Solution: Jest.

Jest. 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.

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.

This is one of the big ones. SPAs have grown more and more complex. Mutable state is particularly troublesome. Solution: React and Redux

React and Redux Reasons for using React: Mind-blowing paradigm shift, breaks a lot of dogmas as old as the web and does it amazingly. Better separation of concerns than traditional approach: instead of separating by technology (HTML/CSS/JavaScript) you break things up by their functionality (cohesive components). Your UI is a pure function of your state.

Mind-blowing paradigm shift, breaks a lot of dogmas as old as the web and does it amazingly. Better separation of concerns than traditional approach: instead of separating by technology (HTML/CSS/JavaScript) you break things up by their functionality (cohesive components). Your UI is a pure function of your state. 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.

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.

Angular2, Vue.js. Warning: You might feel an urge to pry your eyes out with a rusty spoon the first time you see JSX code. Resist the temptation to find a forum and yell in outrage. This is just cognitive dissonance caused by years of indoctrination. Turns out mixing HTML, JavaScript and CSS in a single file is super awesome. Believe me! — Achievement unlocked for using two lame references in a single bullet.

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.

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.

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.

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 ). 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?).

Styling

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.

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.

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.

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 ) with them, which is a deal-breaker in many cases. Alternatives: Inline styles. What I particularly like about inline styles in React is that they allow you to treat styles as regular JavaScript objects, which lets you process them programatically. Also, they live in the same file as your component, which makes them super easy to maintain. Some people still advocate for SASS/SCSS/Less. These languages imply an extra build step and aren’t as portable as CSS modules/inline styles but are as powerful as they’ve ever been.

About Boilerplates

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.

That’s it!

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.