3 reasons why I went framework agnostic and why you should do that too
Tags: javascript, webdev, angular, react
Published: 2019-12-20 10:06:25

I’m a web developer since 2003 and I’ve seen lots 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 and 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 instead of the tools and the architecture required.
* **Reusable code**. Components build with a JavaScript framework are interchangeable, so teams don’t have to invent the 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.

![JavaScript Frameworks: Angular, React & Vue](https://miro.medium.com/max/2000/1*S8i6o8xIxiQ-64RqO45isQ.png)

## The other side of the coin…
In my time as a 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 my problems!](https://miro.medium.com/max/1260/1*zn9HK_ttabxJXuA7lYOOiA.jpeg)

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

1. 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.
2. 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 with AngularJs, which still is going strong needs a new feature to provide a better user experience to the customers.
3. 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.

![There are lots of challenges to face in Web Development](https://miro.medium.com/max/4928/1*KZkc4nIrFnwol9D3OggP3A.jpeg)

The challenge as a company is to increase autonomy within teams and leave them free in the stack choices they make, but in the meantime, you also want to produce high-quality products without incurring too many costs.
The challenge for development teams is not te be held back by legacy or tech stacks which doesn’t suit the way a team works. Developing must be fun for a team in order to produce high-quality apps.

Companies where development teams building apps with modern JavaScript frameworks like Angular, React or VueJs will face the following challenges:

1. Migrating applications to other frameworks or even upgrading them is very time consuming, very costly and very frustrating
2. Components can’t be exchanged between teams, resulting in reinventing the wheel several times which results in wasted time, money and energy.
3. It’s very time consuming, hence a waste of money and energy, to provide a generic look and feel between different parts of an application developed by several teams with a different tech stack

## How to face those challenges?
### Hello framework-agnostic web components!

> Note: If you’re not familiar with framework-agnostic web components, there is a very good introduction you can read [here](https://nhswd.com/blog/web-components-101-what-are-web-components).

![Web Components](https://miro.medium.com/max/700/1*VFpAAEtibhipHMmzCO2Ldg.png)

Framework agnostic components libraries will provide a solution for the challenges described above. The idea of framework-agnostic components libraries is pretty simple but rather complex to do. Development teams are still able to choose a tech stack fit to their needs and develop their part of an app. In that way, the autonomy of teams is guaranteed and productivity will stay enhanced. At the same time, a company develops a framework independent components library, which components are interchangeable between development teams. The key to success is the interchangeability between teams and the agnostic character of components.

## 3 reasons why you should switch to framework-agnostic components libraries
![Using Web Components with different JavaScript Frameworks](https://miro.medium.com/max/1142/1*Kou-7bUwEJBirEVAjBQYRw.png)

Here is why you should switch to framework-agnostic components libraries:

1. No more legacy code. It’s very easy to migrate or upgrade your stack because all the components in the library are framework agnostic. Hence compatible with every tech stack.
2. No more reinventing a square wheel over and over again. Components are compatible with every stack, so there is no need to build the same with different tech stacks. Just imagine how much time, money and frustration that will save!
3. With generic components, it’s easy to provide a uniform look and feel to an application, built by several teams with different tech stacks.

*Stefan helps developers to become Framework Agnostic. If you find his content helpful, you can buy him a coffee [here](https://www.buymeacoffee.com/stefannhs) and get his exclusive e-book "10 reasons to go framework-agnostic" for free!*