JavaScript Fatigue is a thing, get used to it

Anyone who has worked in modern JavaScript libraries can relate to JavaScript Fatigue — the pain and stress that comes along with the pace of change in the JavaScript ecosystem in which we constantly change our mind when it comes to the tools that we use.

I’ll give you some examples, but I’m sure you could come up with this list on your own.

• Many of us built large AngularJS (a.k.a. Angular 1) apps, only to have the Angular team deprecate the “old way” and rewrite the framework from scratch
• “React is great!” – 2015… “React is great, but we all use Redux instead of Flux now” – 2016… “Which of these 20 starter projects do I model my React app off of, and do people still use these libraries? I have no idea what all these config files mean!” – 2017
• The hardest part about starting a new React or Angular project is setting up the dev environment (things like starter kits and angular-cli help)
• Use bower npm! But yarn is better, even though it’s like npm, just faster.
• React and Angular 2 are nice, but what about Aurelia, Elm, Vue.js, etc.? Are those going to make React and Angular 2 obsolete in the next year?
• This post sums it up quite well

If 2018 you reads this post, I’m sure you will notice that it’s outdated. The bleeding edge people are probably moving past all of these tools already.

We can argue whether JavaScript Fatigue is good or bad – there are obvious downsides, but you can also argue that we’re just improving really rapidly, which is a good thing, right?

The reality is that this is the world that we live in, and I don’t think people are longing to go back to the MVC + jQuery days. We complain about this, or we can adjust the way we work so that we can succeed in spite of it.

Write small apps

Let’s face it – your code is going to get obsolete a lot faster. You are going to spend a couple years creating a large app and then want to use a different framework. You’ll want to recruit and retain developers who want to use new stuff.

This doesn’t mean that you’re going to rewrite everything every two years, but if we write modular applications, we have a better chance of switching frameworks incrementally and start building modules in a new framework while keeping the old code running. And if you do need to do a rewrite, now you have a much smaller task in front of you.

Just because there’s a new way doesn’t mean the old way is bad

I’m a fan of most of the things in Angular 2, and overall I think it’s very well structured and easy to work in. But this doesn’t mean that Angular 1 is trash. If I were building a new app, I would obviously pick Angular 2, but Angular 1 is going to work just fine. Many times these new frameworks just shuffle a few things around, give things different names, have different conventions, etc. There are many ways to succeed, and just because someone came up with a new way that worked for them doesn’t mean that we can succeed with the old.

Get used to learning

I hope you’re already used to learning, but in software development things are always changing and we need to keep up. I think we should develop a healthy fear of getting behind in the times. Not that you always need to be using the latest and greatest everything, but you can learn a lot from learning new ways of doing things, and many times you can apply the ideas to your existing applications. Also, you’ll have a better idea of when it’s time to start moving to a new framework. If you don’t know where to start, sign up for Pluralsight and see what’s new. You’ll find all kinds of great content to help get you started.

Avoid company standards

Since the JavaScript world is moving so fast, enforcing company framework standards only ensures that you’re going to be behind. I want different teams to try different frameworks and different ways of doing things, because someone else might learn something that can help me. A great way to learn about a new framework is to have a coworker teach it to you by showing you his working code that is in production.

It’s one thing if your company standardizes on something like .NET/SQL Server/Windows or LAMP or Ruby/Rails/Postgres, etc. because infrastructure is involved. But when it comes to JavaScript, it all runs in the browser, so you can plug and play things much easier.

Relax

You don’t always need to be on the bleeding edge. Remember, the goal is to provide value and create working software, even if you’re using last year’s framework.