How I Avoid Front-end Developer Fatigue

Last updated: February 15, 2018

For years now, bubbling underneath the surface there has been a proverbial sewer of Javascript frameworks and libraries flowing through the community.

It got to the point where it just felt overwhelming for a lot of developers (myself included), around 2016 is when I started noticing people getting fed up.

Looking back over the years, I can remember when jQuery was the new and shiny library. Then it was Backbone for a little while. I also remember when Angular was the developer darling.

Angular is an interesting example, I feel like it arrived on the scene when it was needed. There was nothing like it at the time, at least not until the competitors started showing up.

With things changing what feels like hourly, understandably it feels to some like the carpet is repeatedly being pulled out from beneath your feet. That the goal posts are constantly shifting.

Oh, you just mastered ReactJS? Haven’t you heard, everyone is using Vue now? Pfft, you’re still using Gulp? Everyone is using Webpack now. Oh, you’re still using Webpack? We’ve all moved on to Parcel.

Oh, cool… You just got a grasp of ES2015/ES2016/ES2017 features and syntax? Sorry, too late. We’re not even writing Javascript anymore, we’re coding in WebAssembly using Rust, now.

I say much of this in jest, but there is this culture of constantly needing to find the next best thing, use the most cutting-edge tools and frameworks that cognitive ability can buy.

Let me fill you in on a little secret…

It doesn’t matter what frameworks, libraries, tools or languages you use.

At the end of the day, users aren’t going to use your app because you wrote it using ReactJS and compiled everything using Webpack.

Users aren’t going to flip tables if they discover you’re using Makefiles to do things like concatenating CSS or you’re not using a CSS preprocessor like Sass.

For some reason, developers in the front-end space are hellbent on killing themselves, or the very least shoot themselves in the foot. Most of these new frameworks, libraries and tools are being built by developers. Developers kill developers.

There seems to be this upmanship when it comes to what frameworks or libraries you use. I get it, creating a new build tool or library faster than React will get you internet points for a few minutes. But once the fanfare dies down, you’re just another framework or library in the proverbial wall.

The way to lead a peaceful existence as a front-end developer is to use what you want to use, as long as you get the job done. Stop worrying about what everyone else is doing and using, it’s a liberating exercise.

I am not saying using old frameworks or tools is the way to go, I am just saying that you don’t have to switch over to the new hype.js framework every time a new one comes out.




5 thoughts on “How I Avoid Front-end Developer Fatigue

  1. Yes, I have the same feelings about it. Sometimes I’m ashamed that I develope existing application in old ASP.NET Forms, but client is happy and don’t want change technology because application is written in old one.
    It just works.

  2. Yeah but now Steve Sanderson gives us Blazor, meaning you can produce a full stack in one language. Whether or not you’re a fan (and I have been a fan of Steve’s since knockout.js), you have to admit that the option to support/maintain only one base of code is going to look very appealing to a lot of customers.

  3. One thing to add: In my opinion, it’s also okay to not be an early adopter of every new framework when it appears on the scene. Let the frameworks mature a bit and then look into them. Advantages of that:
    – you will see if the frameworks are going anywhere or if they are just the “It-Framework” of the week
    – you will get more mature tooling
    – you have already much more learning material and resources
    – you can also benefit from already established best practices

    I use this approach for some time and it was very successful. I still work with moder technologies but I do not have to go through the painful early adopter phase. Therefore, I can concentrate on building useful applications instead of trying to debug the latest framework.

  4. After Silverlight crashed and burned, I decided I was going to use a technology that could not be “burned” by someones whim. That is of course plain ole html/javascript, whatever flavor you want to use.

    I am very happy with Aurelia and will never jump ship.

  5. This is very helpful to me especially because am new to this as a front-end developer. I was getting too overwhelmed hearing of different frameworks and libraries coming up yet am here trying to master and get the hang of Javascript. Now I know better. Thanks for this

Leave a Reply

Your email address will not be published. Required fields are marked *