Are Web Components a Good Choice in 2024?

Web Components are a browser standard. But why should we care when we already have Components in React, Vue and Angular?

When I started my web development journey in 2012, it was state-of-the-art to add dynamic behavior to web pages via jQuery.

We were able to reuse code that other developers have written with jQuery plugins.

This was before component oriented JS web frameworks became really popular.

When I started using AngularJS, I never wanted to go back to using jQuery.

But in retrospect, there was one aspect of using jQuery that was really nice.

If you see a React component and think “What a beautiful component, let me use it in my project”, you are in bad luck, if you are using Angular or Vue.

If the component was a jQuery plugin, you could reuse the code in any website or web application, regardless of the surrounding web framework. I.e., jQuery plugins are framework-agnostic.

Why Web Components?

Apart from the universal reusability of jQuery plugins, component-based JS web frameworks are superior in many aspects.

But with Web Components, we have a web standard that allows us to build universally reusable components.

The main benefits I see in Web Components are:

• They are framework-agnostic, so we can use it within any app or page
• They don’t require any library to be shipped to the browser.
• They provide strong encapsulation via Shadow DOM, so we don’t accidentally change internal styles or traverse over internal DOM nodes from outside the component.
• They are future-proof. The browser standard does not evolve as quickly as libraries do, and it’s unlikely that they will be deprecated in the future.

Adoption

One major concern of using browser standards is the adoption of the standard in the different browsers.

At the time of writing, according to caniuse.com the browser support of Web Components is around 97%. This should be sufficient for most modern web pages and applications.

Apart from the good browser support, Web Components are already widely used. This statistic from Chrome tells us that around 15% to 20% of overall page loads register at least one web component:

What can hold us back?

Everything mentioned so far points to the advantages of using Web Components.

But as there is a shadow DOM, there is also a shadow side to betting on this technology.

Some of those issues can be overcome with tooling or may be resolved over time. Others may prevent you from using Web Components by now, depending on your needs.

Low-Level API

While it is great to have a standard for building encapsulated components, the standard does not include tooling for rendering and state management of those components.

If you want to create Web Components without any aiding library, you are left with vanilla JavaScript.

Luckily, there are some libraries to efficiently create maintainable Web Components. I have had a great experience with Lit so far.

Custom Element Registry

Web Components are registered via

customElements.define("my-autonomous-element", MyAutonomousElement);

At first glance, this may look like a nice feature because we only have to register each element once and can use it anywhere within our page.

The drawback is that you can easily forget to register this element. The missing registration will not be raised as an error, instead you end up with a dumb element.

This can become an even more annoying issue with code splitting:

Imagine you have a module A that declares a custom element. Another module (B) renders an instance of the element without directly depending on module A. Now, there may be some cases where module A and B are loaded. In this case, everything works as expected.

But if Module B is loaded without Module A (because a code-split happened between Modules A and B), then the component would not work.

Of course, we can write tests to ensure that the implicit dependency is fulfilled. But those tests would have to explicitly check for this implicit dependency.

In contrast, in most modern web frameworks, component dependencies are checked at compile time. This is much more robust.

Server-Side Rendering

For a long time, SSR was difficult to achieve with Web Components. This technology is heavily dependent on JavaScript. The slotting feature, for example, prevents us from simply placing the pre-rendered content within the custom element.

There is a relatively new feature, called “declarative Shadow DOM” that can be used to pass a portion of rendered Shadow DOM into our web components. caniuse.com reports about 92% of browser support by now, and the feature can also be polyfilled.

The Lit community is currently working on an SSR package @lit-labs/ssr for Web Components built with Lit. But if you want to use it in your favorite SSR library / meta framework, this package has to be integrated into this library. This is an ongoing process.

Bad Integration with React

Until now, React does not allow registering event listeners and writing properties to native elements declaratively in the template . So you would have to work with references to those elements and manage this manually.

Meanwhile, you can use the @lit/react package for creating wrapper-components in React.

Consuming tools and browser extensions

Another issue I recognized when using Web Components was that some Browser extensions, e.g. Speechify, don’t work well with Web Components. Many extensions have to traverse the DOM to work as expected. And to traverse into Shadow DOM, you have to do this explicitly.

HMR

One little annoyance is that Hot Module Replacement (HMR) does not easily work because you can register a custom element only once under its unique name. There are workarounds , but they only partially work.

Decision-making

So, whether it is a good idea to use Web Components really depends on how they will be consumed. Also, some web frameworks may impose a hurdle to efficiently make use of them. It also may make sense to double-check whether browser plugins or other tools that are likely to be used for processing your app or page can handle Web Components.

In the case of my blog, I started off using Lit. One major decision driver to leave Web Components behind and switch to Qwik was the missing support from the Speechify Chrome extension.

For internal and back-office-applications, on the other hand, it is more likely that it makes sense to use Web Components.

Imagine a medium-sized or larger company, with multiple web apps, based on various web frameworks. Now you want those apps to have a more consistent UI, implementing the corporate identity. In this case, it may be a good choice to base a component library on top of Web Components, so it can be easily consumed by all the apps.

All in all, there are plenty of good use cases for Web Components. It makes sense to have at least a rough understanding of this technology to make good, future-proof decisions.

In this sense, never stop learning and happy Coding!