A Map To Modern JavaScript Development (2017)

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

JavaScript flavor

• Problem: ECMAScript 5 (aka old-school JavaScript) sucks.
• Solution: 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.
• 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.
• Solution: babel
• Reason: Works perfectly and it’s pretty much the de-facto standard. Transpiles server-side.
• Alternatives: 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.
• Solution: 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.
• Alternatives: JSLint

Bundling

• Problem: You are no longer using a flat file or sequence of files. Dependencies need to be resolved and loaded properly.
• Solution: 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.
• Alternatives: Browserify
• 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.

Testing

• Problem: Your app is fragile. It will fall apart. You need tests.
• Solution: 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.
• 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 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.
• 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.
• 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.
• 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?).

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

EDIT 1: Corrected link to the post about JavaScript fatigue (thanks, Chris Woods!). Added notes about how other languages also need transpiling (thanks, Ignacio Rossi!). Added Jest to the list of alternative testing tools (thanks, Tiago Pina and Chris Khoo!). Added section about styling (thanks, Tinkerer!). Thank you all for sharing and sending in your feedback!

EDIT 2: Improved section about jQuery (thanks, Eldar Shamukhamedov!)

EDIT 3: Replaced Mocha with Jest in testing section.

EDIT 4: Added note about boilerplates.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.

To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!