- Mar 22, 2016
- 3 min read
There’s currently a huge phenomenon going around the JavaScript community called JavaScript Fatigue. At first this phenomenon was centered around React and it’s community and is spreading like wild fire through the Javascript community.
What exactly is JavaScript fatigue and why do you get it? I believe that this is a result of being a bandwagon jumper. Too many people in the community feel the need to use the latest and greatest tool. Not because it’s the best tool for the job, and certainly not because it’s stable, but because everyone is talking about it. Heaven forbid you aren’t using the latest hotness. Shame on you if you can’t raise your hand and say, “Yeah I use React too!”
Another factor adding to this sense of fatigue is the significant upgrade Javascript recently underwent, something that doesn’t happen often. While most languages see incremental and regular updates, JavaScript’s iterations tend to be minor and more seldom, resulting in less motivation for developers to stay up-to-date. However, the slew of new features that arrived with the advent ECMAScript 2015 seems to have made developers feel a renewed pressure to learn cutting-edge techniques and apply them to their daily code.
Oh god, surely you don’t expect me to learn? I’m too busy building yet another Todo app as a service, I don’t have time to LEARN!
My advice to those who feel fatigued with JavaScript is to pick a toolset and stick with it. These major frameworks and tools aren’t going to suddenly disappear and lose all utility. Gulp didn’t kill Grunt; Grunt is very useful and still has its place, and neither tool is going away anytime soon. The same applies Browserify and Webpack, Angular and React, and most others you can name.
Perhaps the one exception, where I take a strong stance on choosing one over the other is Bower vs npm. Use npm. Virtually anything on Bower is already on npm, and npm has better conflict resolution regarding versions. Why use one package manager to install another package manager to use packages that the former can handle on its own? npm, Inc is doing a great job at being THE package manager for frontend too. npm quite simply is superior, in my opinion.
It’s okay to forego the latest and greatest. I still use Angular 1.x even for new projects. Why? Because it’s not EOL yet. It’s still getting updates regularly. When the Angular Team EOL’s it I’ll reassess, just as I’d do with anything else.
Examine new frameworks and libraries to learn just enough about the core concepts and paradigms they introduce or espouse. Doing so should take no more than an afternoon or two of your time. Then, while you’re still building your Angular 1.x app and a client says “I want a React app!” you can discuss the prospect with the confidence of your fundamental understanding of what React brings to the table, and how it builds upon or differs from Angular.