Let’s play a game.
Write down all the frameworks/build tools/libraries you can think of for 30 seconds straight and then stop.
Ready, set, go!
Ember, Angular, React, Express, Grunt, Bower, npm, Broccoli, Gulp, Lodash, Underscore, rxjs, Knockout, SocketIO, Threejs, D3, Backbone, Ionic, Angular2, React Native, Redux, Alt, Reflux, Webpack, Bluebird, Q, Express, Mocha, Jasmine, Chai, Koa, Less, Sass, Postcss, Impressjs, Revealjs.
Tired yet? In short, that’s what JavaScript fatigue is.
JavaScript Fatigue in Detail
You gotta love JavaScript. This tiny language is now the most popular in the world.
It’s also everywhere. Although it was originally meant to run only on Netscape Navigator.
JavaScript is now the only language modern browsers speak. It has a clear monopoly as others will be lost in the sands of time. Poor VBScript, we won’t miss you.
But JavaScript’s unfair monopoly wasn’t enough for this tiny language. It now runs on servers thanks to node, and mobile apps thanks to Cordova and React Native. It might also run on your fridge sooner than you think.
As JavaScript tackles bigger and more complex problems, we want higher level of abstraction to help us deal with those problems.
JavaScript frameworks to the rescue!
npm is the de facto package manager for both frontend and backend JavaScript libraries. It passed RubyGems and Maven, making it largest package manager for any language.
npm having such a huge number of libraries is both great and awful at the same time. You can find libraries on npm that will help you with anything from machine learning to telling the time.
But there’s so much choice. Too much choice.
Let’s imagine the following scenario
You’re starting your brand new side project. You can choose whichever framework you like. The world is your oyster.
Let’s say you decide to go with React, because it’s the cool kid on the block right now.
To use React you need to transpile JSX, so you’re going to use Babel.
You realize that to use Babel effectively you’ll need some sort build tool. You shop around between grunt, gulp, broccoli, browserify and weback. After careful consideration, you decide webpack is the best choice for you.
You’re now finished with all the fiddling around and can finally start coding.
After a few hours of coding, you realize React is just the view layer of your app. You wonder what’s the best way to manage the state of your app. Soon enough the word Flux comes up.
Luckily enough Facebook released it’s Flux implementation, problem solved. Back to coding.
After reading through Facebook’s Flux implementation, you realize that there seems to be a lot of boilerplate code involved in doing simple tasks. While that might make sense for a huge website such as Facebook, your pet project is better off with something leaner and meaner.
So you start to wonder, are there any other Flux implementations out there?
Between 5 to 20 minutes after you ask yourself that question you encounter this fantastic flux comparison table. This is the part where you start questioning life choices. If you’d have only listened to your mother and became a doctor, they make much less scary and fateful decisions.
You’re now left several choices:
- Go over each of the flux library’s source code and documentation. After carefully reviewing each and every library and doing a small benchmark for each one you decide which library best suits your need. This has been done exactly zero times by no one ever.
- Type into Google “Best flux implementation”. You search until you find 2 separate blog posts which both state the same library as “best”, and go with that. Most popular choice.
- See which library has the most stars on Github. Works best when combined with 2 😃
- Choose nuclear.js because it has the coolest sounding name of the bunch.
- Kill your pet project and go hang out in the sun.
- Learn COBOL. Find a COBOL programmer job. Never worry about any language update or new framework ever again.
COBOL developers don’t have JavaScript fatigue
By the way as of this writing, Redux is considered the “best” right now. I just saved you some time if you chose option 2. Just one more blog post and you’re set.
This is just a tiny example of the many decisions web developers have to make.
And if you’re developer your server-side with node you, you’ll find yourself going through this whole process all over again from scratch. Express vs. * anyone?
JavaScript Fatigue is the result of the JavaScript ecosystem continued growth.
JavaScript is becoming more and more popular. Demand for full stack web developers continues to rise. I’m sure we’ll see many more talented people creating many more wonderful npm packages.
I hope that as the JavaScript ecosystem matures, we’ll see more convergence between libraries. Making JavaScript fatigue just another scary story we tell our kids.