Why you shouldn’t spend one more second choosing a JavaScript framework
Programming has a lot to do with opinion, don’t you think? Well, I don’t. Most of the discussions online on the unquiet realm of JavaScript development fly about “Should I stay or should I go”, well, let’s break down this topic.
Every time a new JavaScript framework emerges, people start bragging about how cool it is, how the features would make an awesome impact on production. But where is the code? Where is the production taking place? Most of the amazing ideas end up as ideas, and that’s kind of sad. Newcomers face a gigantic list of possibilities and ways to do the same thing (this is awesome in a way, but bad at the same time, more on this later). Imagine yourself as a jQuery developer coming to the JS Realm of Crazy Adventures. The first thing you read is “No one writes jQuery anymore”. You may think “well, most of the plugins I used to take for granted died last year, maybe they are right” (and, in a sense, they are, there is better things to do with your life than jQuery). So well… Were to start?
First of all, if you come from the jQuery world, you’ll probably think about the features and interaction needs. Do not dare to look up for “JavaScript framework modals” on Google. You’ll end up falling down the rabbit hole. This is were the problem begins. All this libraries and frameworks were developed by teams of people, most of the time, different people (of course, who would have the time to make 480.192.348 frameworks on a lifetime, anyway), so there are different implementations and tools to ‘just make it work’. A simple task can get really huge, really fast. It’s easy to end up running “npm install -g package-name” for things you don’t even need (the framework needs it, but maybe you don’t).
Eventually, you pick one that seems to be better suited for this particular simple task, according to the comment section on a Stack Exchange question that had nothing to do with your initial problem. Alright! You ‘got shit done’. But how? You’ll need to study. A lot! Who would be mad enough to use something you barely know on production? Here is where you can split your path: either you discover you could be doing a lot more with the framework and decide to embrace it (at the cost of days or weeks) or you try to find out how to implement the other things you need (maybe Ajax, some table manipulation). If you try to think of different libraries (like jQuery and React) as being designed to attend the same problems, you got it all wrong. This is the same as asking if React can change the color of some cells on a HTML table, React wasn’t designed to solve this problem, JavaScript was. You can use JS inside your React app to do it, but React isn’t a jQuery-like library.
You can wrap your head about the JavaScript framework or try to wrap it around your head.
The example may be bad, as jQuery has nothing to do with Angular, React, Ember (as a matter of fact, they don’t have that much in common either). But I think it works. If you’re on Angular right now and thinking about switching to React, just answer: “Why?”. The same thing if you’re willing to jump from Ember to Vue or from {blank} to {{apparently not so blank}}. The point is stop asking yourself what frameworks or libraries you should be using and ask your project about it! Do you really need to know the inside out of the react-router? By the time you finish learning it will be called react-router-dom and everything will be different. Those frameworks and libraries are designed to embrace new stuff all the time and reinvent themselves. They aren’t static. Ember may have a LTS since last year, but the JavaScript community lives around hype, not stability.
There is simply too much people on the JavaScript World of Purple Ponies, people who will rewrite the same app over and over just to make sure it is cool, despite the fact that no-one cares. They end up wrapping the libraries and frameworks around their heads, because they move too fast, so they end up writing tutorials for things the library wasn’t even supposed to deal with (you already saw it!). As the framework isn’t suited to deal with that they try to make orange juice squeezing apples, and the result is an astonishing number of unfinished blog posts trying to make React behave like Angular or Vue handle things like whatever.
Before you jump to the next framework, make sure it’s needed.
You may learn it, of course! The more you study, the better you work. But you don’t need to ‘upgrade’ all of your Angular apps to Vue2, if your team work with Angular. If you change the technology, you should be able to explain why. If “it’s cooler” is your answer, rethink!
The community around cool stuff tend to have a lot of people who barely use the tool, but advocate it everywhere they can (for the next 2 months, when they will jump to the next trend). They have projects in every other technology on their github, but never the one they defend so much. As I said: Where is the production taking place? There’s no time to produce anything when you spend all of your time being cool.
The point I’m trying to make is: if you use a certain framework for most of your front-end developer needs and you think another tool would suit your project better, think about integration. Try to put the two to work together, if it’s possible. If a rewrite is the only way around, go for it, but think twice. If you are new to JavaScript and want to learn a framework, start by looking at the documentation and ease of information. Does it have good courses, books, tutorials? The framework that all the cool kids are using may be too young to have some of those. Then, see what your app really needs. Maybe you don’t even need a full blown framework. Maybe you’ll end up using jQuery.
To sumarize:
You should not spend one more second choosing a JS framework. Your app should choose it.
