software solutions / project leadership / agile coaching and training

JavaScript Fatigue is a thing, get used to it

Posted on February 1, 2017

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.


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.

1 Comment »

  1. [...] JavaScript Fatigue is a Thing, Get Used to It | Jon Kruger [...]

    Für jede Kleinigkeit ein Framework: Warum immer mehr Entwickler von Javascript genervt sind | t3n — March 24, 2017 @ 6:56 am

Leave a comment

I have over 15 years of software development experience on several different platforms (.NET, Ruby, JavaScript, SQL Server, and more). I recognize that software is expensive, so I'm always trying to find ways to speed up the software development process, but at the same time remembering that high quality is essential to building software that stands the test of time.
I have experience leading and architecting large Agile software projects and coordinating all aspects of a project's lifecycle. Whether you're looking for technical expertise or someone to lead all aspects of an Agile project, I have proven experience from multiple projects in different environments that can help make your project a success.
Every team and every situation is different, and I believe that processes and tools should be applied with common sense. I've spent the last 10+ years working on projects using Agile and Lean concepts in many different environments, both in leadership roles and as a practitioner doing the work. I can help you develop a process that works best in your organization, not just apply a prescriptive process.
Have any questions? Contact me for more information.
Ditching the Office - How an everyday corporate development team turned into a remote working team
From Stir Trek 2018
From Stir Trek 2017, cbus.js 2017
Iteration Management - Your Key to Predictable Delivery
From Stir Trek 2016 and QA or the Highway 2015
From CodeMash 2016, QA or the Highway 2014, Stir Trek 2012
The Business of You: 10 Steps For Running Your Career Like a Business
From CodeMash 2015, Stir Trek 2014, CONDG 2012
From Stir Trek 2013, DogFoodCon 2013
(presented with Brandon Childers, Chris Hoover, Laurel Odronic, and Lan Bloch from IGS Energy) from Path to Agility 2012
From CodeMash 2012 and 2013
(presented with Paul Bahler and Kevin Chivington from IGS Energy)
From CodeMash 2011
An idea of how to make JavaScript testable, presented at Stir Trek 2011. The world of JavaScript frameworks has changed greatly since then, but I still agree with the concepts.
A description of how test-driven development works along with some hands-on examples.
From CodeMash 2010
From CodeMash 2010