“JavaScript fatigue” is a term I’ve come across often in the past couple of years. I’m going to work to make the case here why it should not be a thing, or more accurately, why it should not be a bad thing. In fact, I hope by the time you finish this piece you will be celebrating it, or at least adjusting how you look at the state of JS today.

Before you read too far, I want to be up front about the fact that I completely empathize with why developers, both experienced or not, can feel overwhelmed and paralyzed by the vast number of libraries and frameworks out there. I feel it too, believe me. Whom among us hasn’t decided to start a new project and then wondered what we should use to build it. Plain JS? Angular, React, Vue, Meteor, Backbone? That’s just scratching the surface.

Let’s back up for a moment and consider if this isn’t a good problem to have. I would argue it is. Here’s a few reasons why.

In any moment of decision, the best thing you can do is the right thing. The worst thing you can do is nothing.

-Theodore Roosevelt

Reason #1: Having a wealth of options is a good thing

Imagine an alternate reality where we still used AngularJS (a.k.a “Angular 1”) because it was the only viable framework available, because no one has invented a React, Vue or practical alternative, and Google had decided that it had gotten enough right with Angular that they didn’t need to start over and build it again as Angular 2.

Would the open source community that kept up AngularJS be as motivated to make it as good as possible? The development community maintaining this package would no doubt keep making improvements, but would they be as bold and innovative in how they did it, or would they feel comfortable playing it safe and taking it slow because, well, there’s no real competition? Would Google ever get around to recognizing that AngularJS was a great idea with a lot of flaw that it could improve upon?

The existence of other frameworks and libraries that offer real alternatives to a single practical choice used by everyone is something that sparks great ideas, which can borrow from each other or take inspiration from to make something even better

It also gives us real choices about choosing a JS technology that works best for our development goals. There are sometimes good reasons to choose React over Angular, or to pair Electron with Vue, to get maintainable, well-architected code that is well-understood by those creating it.

Reason #2: It helps you to consider different approaches to the same problem

Making a choice about which JS tech to use for a particular project means making the effort to consider the differences between then and why you’d choose one over the others. The nice thing about this is that in the end, you are probably not going to make a choice that leads you to catastrophe. The libraries and frameworks that have gained real traction did so for a reason. It’s not necessary because they don’t have their problems, but in spite of them, they solve a lot more than they create. They make life easier for developers, keep their code more compact and easier for teams to work together on. You’re not likely to find that by choosing React instead of Vue for some project that it was so much harder to get things done. You’ll just be doing things in the React way this time around.

That being said, as things stand today, there are really three major frameworks that stand out in JS world for most serious projects: React, Vue and Angular (that is, Angular 2 and above). It’s not that there aren’t other serious contenders, or that these three are just the best. It’s just that they are generally safe bets for most projects that have strong community maintenance with backers like the best minds at Facebook and Google standing behind them. If you want to go use some other, less popular framework or library, go for it. I’m just trying to pare down the list for you a bit so you can spend less time fretting over which one go go with.

Reason #3: It really helps make JS easier to work with

I love working in JavaScript, but there are a lot of things about it that I could do without. They aren’t things that bother everyone, but I have…feelings about them. Like it’s weak typing. I cut my teeth on programming on C++ and Java where you could never get away without declaring the type for everything, and so I just have some reservations about a language that lets you just pass any type to a variable or object without any concern that that type makes sense in this context. So I prefer to work with Typescript, which is a superset of JavaScript that gives you the option to force strong typing in your code, along with a lot of other things. Typescript has been taking the development world by storm and for good reason.

Maybe you’re not a Typescript fan, and that’s fine. The point is not to sell you on Typescript, but to get you to stop thinking that the only real JS developers write everything in plan JS. If you want to use plain JS, go ahead. I learned it, and I can code in it, and it is going to be faster than any framework or library out there. For myself, in most use cases that go beyond a CodePen experiment, I prefer something that offers to help me manage my code architecture more easily, strongly type my object definitions, and gives me just a few more guardrails to avoid making critical mistakes I won’t catch until someone breaks my app. That’s just me; there are perfectly rational arguments for sticking with vanilla JS. I would just encourage you to understand why you’re choosing the approach you take. Most developers that plan to work in an engineering role in a professional capacity outside of freelancing are going to have to pick up one or more technologies like React or Angular at some point.

If you’re not sure what you want to use for your next personal project, just pick one and write some code! I guarantee you can finish what you started if you want, or you can go back and try a different system if you think it might work better. No matter what happens, you’re going to end up gaining knowledge and experience, and you can’t lose that way.

The takeaway from all of this is that it’s a matter of perspective whether you are going to feel overwhelmed by all the choices you have when it comes to JavaScript, or if you are going to feel liberated. Be bold, try different things, embrace your many options, and leave JavaScript fatigue in the dustbin where it belongs.

Photo by Jared Rice on Unsplash