Let me start by asking: Have you ever felt like you’re building the same UI components over and over, just for different projects? I’ve been there. As someone who’s worked on various webapps to smart home platforms, one thing that always bothered me was having to recreate the same components over and over again for different projects or frameworks. When Web Components first started gaining attention, I was interested in the idea of building reusable elements that could work anywhere, without being tied to a specific framework like Angular or Vue.

But is this tech finally mature enough to replace the monstrosity of boilerplate code? Let me walk you through my journey.

Early on, though, I tried using Web Components in a startup project. The idea was simple: create a reusable dashboard widget for a travel app. But I hit a wall.

  • Browser support was spotty. Shadow DOM, the core of Web Components, didn’t work in IE or older browsers.
  • Tooling was fragmented. I had to manually write <custom-element> tags, manage CSS encapsulation, and deal with quirks like is attributes.
  • Framework conflicts? yeah. If I used React or Vue, the components felt like third-party plugins, not first-class citizens.

I ended up abandoning Web Components for a custom React-based UI library. But that was before the “maturity” part.

General speaking, the experience was rough. Browser support was inconsistent, and working with Shadow DOM and custom elements felt clunky. Tooling was limited, and integrating them into existing projects often created more problems than it solved. Because of that, I mostly stuck with framework-specific component libraries for a long time.

Things started to feel more practical a couple of years ago. The ecosystem around Web Components has improved quite a bit, especially with libraries like Lit. Lit makes it much easier to build and maintain custom elements by handling a lot of the repetitive work around templates and reactivity. Instead of writing a lot of boilerplate, we can define components in a cleaner way that still gives us the benefits of encapsulation through Shadow DOM.

One of the main advantages I’ve seen is being able to create components that can be used across different projects or even different frameworks without much friction. If you have a design system or a set of shared UI elements, Web Components can help reduce duplication. You build them once and can drop them into various applications without having to rewrite them for each framework.

Web Components aren’t always the best solution. If you’re working entirely within one framework, using that framework’s own component system is often simpler and more productive. The real value tends to show up in situations where we need to share components across multiple codebases or teams that use different technologies.

There are still some trade-offs. Styling can sometimes be more complicated than in traditional frameworks, and debugging can feel a bit harder at times. Performance is generally good, but it depends on how we structure our components. It’s also worth noting that while browser support has improved a lot, we still need to be mindful of older environments if our users haven’t moved on.

Overall, I think Web Components have reached a point where they’re worth considering for certain projects, especially when reusability across different stacks is important. They’re not going to replace framework-specific components in every situation, but they’ve become mature enough to be a reasonable option instead of just an experimental one.