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 community that the term “JavaScript fatigue” actually exists. When you have time for some comedy about the subject, reflects the phenomenon brilliantly. JavaScript this post 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 . 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. development 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 Need to organize your project and your dependencies. Problem: NPM and Yarn Solution: 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). Reason: None that I know of. Alternatives: JavaScript flavor ECMAScript 5 (aka old-school JavaScript) sucks. Problem: ES6 Solution: 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. Reason: TypeScript, CoffeeScript, PureScript, Elm Alternatives: Transpiling 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. Problem: babel Solution: Works perfectly and it’s pretty much the de-facto standard. Transpiles server-side. Reason: Traceur Alternatives: 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. Notes: Linting There’s a zillion ways of writing JavaScript and consistency is hard to achieve. Some bugs can be prevented with a linter. Problem: ESLint Solution: 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. Reason: JSLint Alternatives: Bundling You are no longer using a flat file or sequence of files. Dependencies need to be resolved and loaded properly. Problem: Webpack Solution: Highly configurable. Can load all sorts of dependencies and assets. It’s pluggable. It’s pretty much the de-facto bundler for React projects. Reason: Browserify Alternatives: Can be a little hard to configure at first. Disadvantages: 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. Notes: Testing Your app is fragile. It will fall apart. You need tests. Problem: Jest. Solution: Batteries included, , can detect tests affected by your changes and run only those, works nicely with monorepos, comes by default with CRA, backed by Facebook. Reason: snapshot testing Jasmine, Mocha, Tape. Alternatives: UI framework / state management This is one of the big ones. SPAs have grown more and more complex. Mutable state is particularly troublesome. Problem: React and Redux Solution: 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 React: 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. Reasons for using Redux: Angular2, Vue.js. Alternatives: 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. Warning: DOM manipulation and animations Guess what? You’ll still need occasional quickfixes where you’ll have to target selectors and perform operations directly on DOM nodes. Problem: Plain ES6 or jQuery. Solution: 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. Reason: querySelector Dojo (does that still even exist?). Alternatives: Styling 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. Problem: CSS modules. Solution: 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. Reason: :hover 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. Alternatives: About Boilerplates Boilerplate projects like 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. Create React App 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 Corrected link to the post about JavaScript fatigue (thanks, !). Added notes about how other languages also need transpiling (thanks, !). Added Jest to the list of alternative testing tools (thanks, and !). Added section about styling (thanks, !). Thank you all for sharing and sending in your feedback! EDIT 1: Chris Woods Ignacio Rossi Tiago Pina Chris Khoo Tinkerer Improved section about jQuery (thanks, !) EDIT 2: Eldar Shamukhamedov Replaced Mocha with Jest in testing section. EDIT 3: Added note about boilerplates. EDIT 4: is how hackers start their afternoons. We’re a part of the family. We are now and happy to opportunities. Hacker Noon @AMI accepting submissions discuss advertising & sponsorship To learn more, , , or simply, read our about page like/message us on Facebook tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our and . Until next time, don’t take the realities of the world for granted! latest tech stories trending tech stories