Stefan helps developers to become Framework Agnostic. If you find his content helpful, you can buy him a coffee here and get his exclusive e-book “10 reasons to go framework-agnostic” for free!

I’m a web developer since 2003 and I’ve seen lot’s of tech stacks come and go. Back then there was no such thing as a JavaScript framework and the language was not as advanced as it is today. It was even considered an inferior language, compared to Java an C (while it actually is a completely different thing). With the introduction of frameworks like React, Angular and VueJs JavaScript finally became mainstream and now the web depends on it.

Today’s web is impossible to imagine without JavaScript frameworks. Building JavaScript applications with the help of a framework provide lot’s of advantages like:

Save energy. Modern JavaScript frameworks are packed with best practices, scaffolding tools, paradigms and industry standards which enables developers to set up an app in no time. It enables developers to focus on developing the actual app in stead of the tools and the architecture required.

Modern JavaScript frameworks are packed with best practices, scaffolding tools, paradigms and industry standards which enables developers to set up an app in no time. It enables developers to focus on developing the actual app in stead of the tools and the architecture required. Reusable code. Components build with a JavaScript framework are interchangeable, so teams don’t have to invent a square wheel twice.

Components build with a JavaScript framework are interchangeable, so teams don’t have to invent a square wheel twice. A common language for teams. Using a JavaScript framework generates a common understanding between both front- and backend developers. Everyone speaks the same, common language.

It’s because of these benefits that almost all frontend development teams are using JavaScript frameworks to build apps.

The big three: ReactJS, Angular and VueJs

The other side of the coin…

In my time as web developer I’ve worked on numerous projects and a new project always starts with choosing a suitable JavaScript framework. What a perfect way to start a project! A framework will solve all of my problems and will save me a lot of time and energy! Other teammates and even other teams will completely understand the architecture and components I’ve built, Right?

“A JavaScript framework will solve all of my problems!”

Let me give you 3 real world examples from companies I worked for:

I used to work for an, enterprise size, company where multiple frontend development teams worked on different parts of an app. All teams choose Angular as their preferred JavaScript framework. Together they’ve built a shared components library in Angular (v2) to save time, money and energy, but there was a catch. Angular (v4) came out and a few teams did an upgrade. The new version contains some breaking changes and the teams quickly realized that the shared components became useless. The idea of the shared components library was to save time, money and energy, but the opposite was actually the case. Teams have to invest extra time, money and energy in upgrading the shared components library; A waste and a source of frustration.

Another project I worked on was for another enterprise company that has developed an app in AngularJs. It still works, but the responsible team has moved on and did other projects and so is their tech stack. They moved forward and switched to Angular as their preferred JavaScript framework. New team members are hired and aren’t expected to learn AngularJs anymore. But guess what? That application, built in AngularJs, which still is going strong needs a new feature to provide a better user experience to the customers.

I worked for a company where multiple frontend development teams, with different tech stacks, worked on different parts of an app. The teams are known to be self steering and very autonomous. A challenge for companies that want to provide a consistent user experience and look-and-feel to end users. The big problem for the teams (and the company) is that components are unexchangeable between teams, which is hugely time-consuming and cost-inefficient.

The common theme running through these real world examples is inefficiency and I bet that it happens in your company too.