Stefan Nieuwenhuis

Posted on Dec 20, 2019 • Updated on May 21, 2021

3 reasons why I went framework agnostic and why you should do that too

#javascript #webdev #angular #react

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.

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?

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 with 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.

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:

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

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.

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

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!

Top comments (20)

Andrew Colclough • Dec 20 '19 • Edited

This is the exact reason I have been moving to Svelte - because it compiles out to just JS. Everywhere I have worked, we have always run into clashes of frameworks, and trying to shoehorn a certain approach (or even a different version of the same approach) into something incompatible. The technical debt quickly became unmanageable. With Svelte components, we deliver just...Javascript, but we still get a ton of great framework features. Worth a look.

Stefan Nieuwenhuis • Dec 20 '19

I haven't worked with Svelte intensively, but I hear great stories about it. Must take it for a spin soon.

Andrew Colclough • Dec 20 '19

Yeah, I highly recommend it. We have it setup so that we can build components, and dump them out as simple JS packages.

Something like this is all our teams need to do to consume one:

    const yourComponent = new yourComponent({
      target: document.getElementById('someElementID'),
      props: {
        propKey: propVal,
        themeBackground: "#ffffff",
        themeicon: "#989999",
      },
    });

We have sorted out passing in theming, data API details, and also dumping out bundles that work in IE11.

It was a little trial and error, as everything is new, but it's been more than worth it, because Svelte is so nice to work with.

It's worth a look. (Actually, I should write a post about all the little odds and ends we sorted out to get this thing flying. Might be helpful for others.)

Stefan Nieuwenhuis • Dec 20 '19

That looks so awesome! That you even made it work with IE11 is really cool. What about polyfills? And do you have a link to a GIT repo or something?

Andrew Colclough • Dec 20 '19

ok, ....Clearly I need to write about this. HAHAHA!

Yes, we got things working in IE11. We use babel for shims and polyfills, and we happened to be using fetch which requires a separate polyfill. The downside is that this took a 20k bundle, and bloated it up to about 103k. I kinda hate that, so I am currently R&Ding how to deliver a big fatty IE11 bundle, and a nice sleek bundle for everyone else.

You have inspired me to write a big summation post, with links to resources. To solve all these challenges I was on a wild goose chase across the interwebs, and if I can help anyone else avoid that, I would be happy. lol.

I don't have a repo I can share, as this is internal, but I will create something to share soon.

Stefan Nieuwenhuis • Dec 20 '19

I totally understand that you cannot share an internal repo. I have the same problem as well...I feel blessed that I've inspired you to write your own post. I can't wait to read it!

Please share it once it's ready :)

Andrew Colclough • Dec 20 '19

Totally will!

In the mean time, here's just some silly thing I have been playing with to test out Svelte concepts.

svelte.dev/repl/32f9c97b2c4f4da0a4...

I'm also using this to teach my oldest (7yrs) about programming. ;) But it's so nice to work with. Svelte gets a ton of overhead out of the way.

Cristina Ruth • Dec 20 '19

Interesting read. I've noted down to look into your suggested framework agnostic solution.

I agree there is a cost to using ready to use things especially frameworks. Good points around sharability between teams and also how each framework needs maintenance and would need upgrades.

Looking forward to reading more about framework agnostic. But curious on what the downsides are, how new it is, the developer community presence behind it, and gotchas/things to watch out for.

Gerard Klijs • Dec 20 '19

It's not really new, but web components are currently properly supported by the major browsers. So it's useful now. One of the caveats is global state. For example if you have an application where you have some profile data stored in de backend. And almost all the components need part of that data. But you could have a web component for that. But having dependencies on other components complicates things.

Stefan Nieuwenhuis • Dec 20 '19

I think managing global state is rather an architectural challenge and not so much about web components. Every application, unregarding the framework used, has to deal with a global state in one way or another and every framework or library has its own solution for it. Just take a look at Redux, RxJs, NgRx or Vuex and all the different patterns (for example the Container Components pattern in React) invented to handle (global) state effectively.

Cristina Ruth • Dec 20 '19

Agreed. Global state is tricky indeed. Then you add in backend and persistence and it becomes more complicated.

Radu • Apr 15 '21

there's a promising state management library at sam.js.org. It is inspired and follows the semantics of the Turing Award winner Dr. Leslie Lamport's TLA+. It is also framework agnostic. You should check it out!

Stefan Nieuwenhuis • Dec 20 '19

Thank you so much! I'm glad that you enjoyed my post and I'm planning to write much more on Framework Agnostic Topics, so keep an eye out on my blog! :)

Stefan Nieuwenhuis • Dec 20 '19

I completely agree with you. Web Components aren't the holy grail of Web Development but have their own specific purposes and you don't have to ditch all frameworks in favor of framework-agnostic solutions, because they are there for a reason. So I'd say: Make use of the best of both worlds :)

Gábor Soós • Dec 20 '19

Long live webcomponents! We are doing the same at my company and it saves so much time for the autonomous teams 👍

Stefan Nieuwenhuis • Dec 20 '19

That sounds awesome! And what about consistency?

Sandor | tutorialhell.dev • Aug 24 '20

I am looking into adopting this approach for our project. I wonder if anyone has experience with setting up the build process for development and production with framework agnostic approach? Ideally, I want to have the build process replaceable meaning that I may use Webpack and then later, switch to Parcel or anything else.