Let me give you 3 real-world examples from companies I worked for:
- 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.
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.
- Migrating applications to other frameworks or even upgrading them is very time consuming, very costly and very frustrating
- Components can’t be exchanged between teams, resulting in reinventing the wheel several times which results in wasted time, money and energy.
- 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
Note: If you’re not familiar with framework-agnostic web components, there is a very good introduction you can read here.
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.
Here is why you should switch to framework-agnostic components libraries:
- 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.
- 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!
- 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 and get his exclusive e-book "10 reasons to go framework-agnostic" for free!