How about not boarding the hype train? Why you should carefully consider your goals before jumping on new frameworks and trends every second week.

Image from this article

As developers we all know the feeling: there is a new framework, library or other shiny new thing coming out every week and you feel excited (or slightly pressured) to check it out and learn it. But should you?

I had my fair share of learning new things in web development. From table-based layout to floats, flexbox, now grid. From jQuery to Backbone, Ember, Angular 1 now React, Vue, Moon and whatever else came out since I started writing this. This is true for the complete Stack of CSS, Javascript, Deployments, Workflow-Tools, Build Scripts in all combinations and variations. It’s daunting.

From my experience, most developers belong to one of two camps when working on a project and I’m always thinking about in which one I am before making technology decisions.

  1. You have an existing codebase that you need to improve
  2. You start a new project where you’d need a working version asap

Maybe you experienced it already, a new developer joins a team with a 3 year old product and its codebase is Angular 1. The new developer wants to rewrite everything in React — right now. Should you do it? What does that rewrite achieve for the team, the product and the business?

Or you started a new side project or prototype. You want to pump out an MVP as fast as possible to test the product on real users only to find yourself two weeks later still optimizing the webpack build or reading the docs of that new framework you wanted to test out.

Sounds familiar? Same here.

Who do you think is more successful: A developer that knows the top 5 frameworks in and out? Or a developer that pumps out 5 MVPs per month?

If you need to develop prototypes and MVPs fast, be it at work or for your side-projects, the answer is simple: stay with what works for you. The user doesn’t give a squirrels fart about vue.js, PHP or Go. If you can make your product work with what you already know, just build it how you’re used to it.
On top of that, if you’re like me and you build new side projects every week, switching between them is a mess when every project has a different setup.

If you’re working on a codebase for some years already it’s a bit different. Sticking to the old might make it harder to find new developers. It can drag down a teams motivation if they can’t try/use new tech. And there might be tech dept or problems that are solved in one of the new technologies.

That last part is the sweet spot to have enough leverage to do a gradual or complete rewrite in a new technology. At least from a business side it needs to solve actual problems (because again: the user won’t care). Like using complicated workarounds to get Angular and ngRepeat on Arrays with a length of over 2000 working without lags. That one is solved by React and Vue. Or the spaghetti code of huge jQuery projects that makes every release and bugfix a nerve wracking show in which unforeseeable new bugs arise. MVC or component based frameworks solve this.

My point is: if you are curious about something, try it. But don’t force yourself, your team or your product to be on the latest tech all the time if the only reason is to be on the latest tech.

If you have the goal of learning new tech and pushing a product forward, think carefully if they’re mutually exclusive or not. And then act accordingly.

I wish you all the best in pursuing this.

Have a great week,

If you like these articles you should check out my mailing list where I send them out weeks before they appear here plus some exclusive ones 🙌.