Reading Hacker News comments on JavaScript frontend articles is a depressing task these days. The majority is complaining: Tooling too complex, bundling too complex, Too many different frameworks, best practices change too quickly.

Spearheading: The React ecosystem. Completely modular with an abundance of libraries, patterns, and abstractions, pushed by an enthusiastic, Facebook-backed community eager to iterate on best-practices over and over.

The reasons for the frustration are manifold (see here or here). But let me quote one HN Commenter:

When React first started getting popular all you read about was how simple the API was and how it was Easy to Reason About™. Fast forward to today and you need to have working knowledge of WebPack, ES6, Redux, immutable.js, Babel, and a bevy of other dependencies to be aligned with the React ecosystem's ever-evolving best practices.

Why did it turn out like this? My diagnosis: When people hype patterns or libraries, they do not tell you the most important thing: When you don't need it.

It is therefore only reasonable that some people assume they need everything that trends on HN and they get frustrated by it.

This is why I believe react-howto is the most valuable repository in the React ecosystem. An absolute must read for everyone. Go read it if you haven't.

I would like to add some additional points that are worth to be mentioned to avoid JavaScript fatigue (in the React context).

Do You Need React?

React-howto forgot to mention that you might not need to know much about React. It takes time to pick it up after all, even if you don't get paralyzed by all the buzzwords.

If you:

Are knowledgeable in at least one other frontend technology and you feel productive and don't spend hours of debugging.

Want to get into web development, and your goal ist to write a simple CRUD application with limited interactivity.

Don't bother with React.

Only if some of the below points ring true, it's worth the time to dig in:

You are doing progressive enhancement and your JQuery stuff is buggy and hard to maintain.

Your existing SPA frontend stack is riddled with hard to track down bugs, you are in event chain hell, or you have performance problems when interacting with the DOM.

You are new to web development and your goal is to write an interactive, stateful app.

You are interested in new stuff, because it's new stuff

First Project after the Official Tutorial

It is important to know how to get away from the playground. Here is my advice:

If you have an existing web application

Try to replace a tiny, interactive, independent component with React in your current application. You should be able to plug React in any other stack, be it progressively enhanced server-side rendering or a single page application. Try to avoid tooling if you are not proficient with it. Injecting React globally via a script tag is just fine.

If you are new to web development:

You have no choice to bite the bullet and check out the simplest boilerplate (like this, NOT this or this) you can find where you can get going ASAP. Focus on building things with vanilla React.

JSX Yes or No?

The discussion is a textbook case of bikeshedding. It doesn't matter if you use JSX or not, trust your instinct and choose. Pros and cons are balanced. There is no way it will affect your project substantially productivity wise.

You won't believe me but: Mostly not. Let me state something else: It hasn't happened in the past either.

From the outside, the turnover of best practices looks much bigger than it is. The most significant advantages of React were established when it was released. The API of React has been more than stable enough.

After the initial Flux pattern (which was so simple, it was boilerplate and a Dispatcher module) an enormous amount of Flux libraries emerged. This seemed to stress out people. Unnecessarily, in my opinion: If a huge number of libraries appear for a problem, it means that the problem is not hard, so why worry about it?

Besides, people forgot to mention that there is a good chance you don't need Flux at all. Too bad it's (afaik) not mentioned in the otherwise well-curated docs of Redux on which the community has settled for now.

To be honest, I think that the improvements of Redux over the original Flux pattern are minor if seen in the big picture.

Redux is quite immaculate from an architectural point of view. But the reality is: The improvements are almost irrelevant for most projects regarding efficiency, considering all the big time dumps a project brings. I'm sure Facebook has the "vintage" pattern littered all over the place.

The Right Mindset

Be aware that you are working on a project with specific properties. These may differ significantly to the ones the people that push out new technologies are beeing exposed to.

The web has a bigger disparity of project properties than most other environments. You can provide so many things through the web, it is only natural that many different technologies arise.

Whether you actually need something depends on many factors: Team size, project size, project domain, maintenance intensity, and many others.

Some technologies provide a use for many different settings (for example, React itself). Things like Flux are only useful for a decent variety of projects. Other things are for very specific kinds of projects (like Isomorphism, GraphQL or Relay). Most "new, hot things" are useful (hence the hype), but maybe only for solving problems a few people face.

Since nobody tells you what you need to solve your problems, people resort to just doing things because the cool people do it, or because the technology is cool from a technical standpoint. This will lead to a lot of wasted time learning things that are not needed in a project. However, looking at nothing will not make you improve. So what do you do?

What works quite well for me is this:

I only skim stuff and take a mental note of the buzzwords. I also have a mental list of the top five problems/time-dumps my team faces in the active codebase (If you can't assemble that list for your project because you think everything is ok, you most likely have a blind spot.)

For that problem list, I don't have an easy solution and for some, there probably isn't one. But sometimes the hype buzzwords of a "new hot thing" match one of these problems. Then I spend some time on that topic. Before I assess the quality of the solution, I make sure the people that created it were facing similar problems I am facing.

That's how I stumbled into the tech-stack I currently use:

React because I was wasting time optimizing renders with Backbone.js/Chaplin

Flux because I had an application with a lot of shared state and was wasting time passing handlers all over the place

TypeScript because our team was wasting time with runtime errors

etc. etc.

Of course, everything from this list might be irrelevant to the problems you are facing.

Don't feel bad that you are not using something, be happy about it! Everything I mentioned above took a time investment to get into. It is only worth investing if the return on it is positive, which in development means saved time going forward.

Your job as a developer is to maximize productivity given the project, not doing "best-practices / cool things" that don't actually save resources in the future.

Once you gain confidence that you don't have to know about every hype because it doesn't concern you (at least at the moment), JavaScript fatigue will be a thing of the past.