Dave Rupert blogged a bunch of reasons about why you probably aren’t using them yet. Some of it is technological, and more of it is historical, marketing, and psychological reasons. Then Dave, a pretty avid Web Components follower and advocate, followed up with another surprise. Should you rewrite your app to use them? Probably not.
It’s not that you shouldn’t use them because they aren’t good, it’s:
If your components only have one place to go, then you probably don’t need Web Components. Even if your components service a couple different apps or product teams that all use the same uniform tech stack, you probably don’t need Web Components. Where Web Components shine is when your components need to go to many places.
The grid of logos on https://arewebcomponentsathingyet.com/ tells that story: very big companies.
Nolan Lawson followed that up with Use web components for what they’re good at, a more specific take on this, which largely agrees with Dave. Big companies are reaching for them because they solve actual problems for them. But enterprise isn’t very present on social media, so you just don’t hear about it as much.
So why are big enterprises so gaga for web components? For one thing, design systems based on web components work across a variety of environments. A big company might have frontends written in React, Angular, Ember, and static HTML, and they all have to play nicely with the company’s theming and branding. The big rewrite (as described above) may be a fun exercise for your average startup, but it’s just not practical in the enterprise world.
Having a lot of consumers of your codebase, and having to think on longer timescales, just leads to different technical decisions. And to me, this points to the main reason enterprises love web components: stability and longevity.
If you have some of those problems, you’ll probably benefit from Web Components and could or should use them, or maybe you already are. If not, whatever. Nobody needs permission to use them, and plenty of companies are doing it without a single care about what the social media vibe is on them. Web Components still have some problems, and fortunately, are still being actively worked on, so the story should get better year after year, in case you’re on the fence and watching.
Nolan does shout out one thing Web Components excel at, obviously and immediately:
To me, [client-rendered leaf components are] the most unambiguously slam-dunk use case for web components. You have some component at the leaf of the DOM tree, it doesn’t need to be rendered server-side, and it doesn’t
<slot>any content inside of it. Examples include: a rich text editor, a calendar widget, a color picker, etc.
Dan Ryan has another take: they can be really simple. He used a header component as an example, which didn’t buy them anything extreme — just a simple update for a simple benefit.
So what did this gain us? For this example not much really. But where it really shines for us is only loading the CSS needed for the components used on a given page. Most of our visitors only view a single campaign page which uses just a few components. Previously though we were bundling all our CSS into a single file and serving it to everyone.
I’m the biggest fan of Web Components when you can just pluck one off the shelf and use it for something useful, knowing it’s lightweight and flexible. Nolan’s own emoji-picker-element is a classic example. When I see one-off componentry that isn’t a Web Component lately, I immediately wish it was. Check out this OverlayScrollbars “plugin”. Wouldn’t it be awesome as an <overlay-scrollbars> component, making it declarative and easy to use? (Yes.)
But I’m down for bigger approaches, too, so long as they are solving a problem. Google’s Material Design is an example of that. Material 3 is their latest take, and it seems to be mostly leaning into native apps, with the web version “coming soon”. When it does, it appears as if it’ll be Web Components-based. That’s cool and maybe even a touch surprising, being that Google could have used it as a way to promote Angular. But just because they went Web Components doesn’t mean they didn’t go Angular, assuming they work nicely in Angular, which let’s just hope they do.
Allow me to end with a little linky-uppy: Tram-Lite. I really like how you just use HTML to define the whole component, then go on to use it elsewhere. It requires no build process and has a very native feeling. Actually, check out the principals — they seem sound to me. And I’m not just saying that because it works great on CodePen.