A Web Component Story

Gather 'round, it's story time.

A number of years ago, I was hired by a company to rebuild a component library for their design system. The one they were replacing was built with AngularJS, but AngularJS was old and rickety and nobody wanted to use it anymore. Plus, many teams had moved on to other frameworks and one team even preferred doing everything with vanilla JS.

But the company couldn't hire for AngularJS. There was no talent available. Devs had moved on. Nobody wanted to work with a "legacy framework."

So they had to build something new to get out of that ecosystem. They talked about building a new component library in modern Angular. Or maybe React. A handful of engineers wanted Vue.

But they knew that whatever framework they chose, they would be locking teams into it or forcing them to build their own components. This would mean duplicating effort and risking stylistic and behavioral deviations — an inevitable side effect of competing libraries.

They also knew that they'd be doing this again in a few years if they picked any of today's popular frameworks, so they decided to give Web Components a try.

So that's what we built, and that's what they still use to this day. It no longer matters if their teams want to build with React, Vue, Svelte, Solid, or whatever tomorrow brings.

• Nobody is forced to use a specific framework
• Nobody needs to reinvent UI primitives
• Upgrading or switching frameworks is much easier
• No duplicate efforts

At this point, you might be thinking "we only use React, so who cares?" And you can get away with that for awhile, especially if you're a single team or a small shop. I get it. React feels good and it's sticky. But all frameworks eventually fizzle out.

Thanks to Web Components, large companies are realizing you don't need to rebuild buttons and other UI primitives every few years. Teams don't need to argue about frameworks anymore. You can have your cake and eat it too!

It's already happening on a large scale at some of the largest companies in the world, but the impact isn't limited to big players — everyone can benefit from Web Components today.

To be clear, I'm not suggesting you throw out your framework and go all in on Web Components...Web Components are complementary to frameworks! In 2022, I strongly suggest building your design system with them. Knock out the UI primitives and patterns that all teams use and give devs the freedom to build with whatever framework(s) they want!

Any org that goes all in on a single framework will eventually find themselves swimming upstream to hire talent to maintain legacy code and avoid framework rot. But you can reduce this burden (and the associated costs) by using Web Components in your design system.

Remember that design systems aren't cheap. It takes a lot of time to redesign and rebuild dozens of components, so why keep doing it every few years? It costs too much and it prevents you from shipping faster.

Here's a quick case study from an open source UI library called Element UI. This is a very popular Vue 2 library, but breaking changes in Vue 3 meant the library no longer worked! They had to build and maintain a completely different version of the library, and now they maintain two separate versions — one for Vue 2 users and one for Vue 3 users. 🤦🏻‍♂️

This is what happens when you go all in on a framework for UI primitives. Imagine having to maintain multiple versions of your component library for each framework — and each major version — you want to support.

Thanks to Web Components, this it totally avoidable!

A common criticism I hear is that Web Components aren't perfect, to which I'll agree. No, they're not perfect. But they're pretty damn good, they're part of the standard, and we can collectively work to improve any shortcomings they might have.

I'll take platform-based interoperable components over framework churn any day of the week. ✌🏻

Shameless plug: you should take a look at Shoelace if you're looking for an awesome library of web components.

This post was originally a Twitter thread.