Web components are a set of web technologies that allow us to create reusable HTML elements. They make it possible to develop framework-agnostic, custom components that use the HTML syntax. Browsers can natively interpret them without a third-party library such as React or Vue.js.

These days, web components are a divisive topic. They were once expected to revolutionize frontend development, but they’re still struggling to achieve industrywide adoption. Some developers say web components have already died, while others think they’re the future of web development.

Let’s zoom in closer and explore what web components are, why developers are reluctant to use them, and what the future holds.

Where can you find web components?

One of the most asked questions about web components is where or how to find them. Currently, web components don’t have a distinct home. It’s not that they are completely homeless. Rather, they’re couch-surfing within W3C’s extended ecosystem.

Originally, web components had a standalone W3C specification called Custom Elements. Custom Elements was deprecated in 2018 and its parts moved into the HTML and DOM standards, respectively:

• Custom elements (defined in the HTML Living Standard specification)
• HTML templates (represented by the <template> and <slot>elements, also defined in the the HTML Living Standard specs)
• Shadow DOM (defined in the DOM Living Standard as shadow trees)

The web components technology used to have a fourth element, HTML imports. HTML imports aimed to package HTML modules as .html files so that they could be easily imported without JavaScript. HTML imports were abandoned by browser vendors, so even though they’re still working with a polyfill, it’s not recommended to use them in new applications.

Just like there’s no distinct home for specifications, there’s no central place or library where you can find and download open-source web components. Even though there are some promising projects (we’ll look at some of them below), you have to find them on your own.

How do web components work?

Before delve further into the issues of web components, let’s quickly review how they work.

Here’s the basic process of setting up a web component:

1. Create a MyElement class that extends the HTMLElementclass (using ES6 syntax since previous JavaScript versions don’t have a class syntax)
2. Define the <my-element></my-element> custom HTML tag that will represent the MyElement JavaScript class in the HTML document. Here, you can use either the CustomElementRegistry.define() method or the DOM API’sdocument.createElement()method
3. Attach a shadow DOM tree to the custom element’s constructor using the Element.attachShadow() method. This step is optional and only applicable when the web component has child elements — see a web component example without (<flag-icon></flag-icon>) and with (<popup-info></popup-info>) a shadow DOM
4. Create an HTML template using the <template> tag. Place the reusable content of the custom MyElement web component within the template and append a clone of it to the shadow DOM. You can also add <style> and <slot> tags (the latter is for dynamic content within the template) to the template. This step is optional, too, you only have to add a template if you want/need to
5. Import MyElement as an ES6 module
6. You can use the <my-element></my-element> web component on your page the same way as any standard HTML element

Why people aren’t using web components

Web components have promised many awesome things. Why aren’t more developers using them?

It’s not due to a lack of interest for a browser-native technology that extends HTML and makes modular frontend development easy and fast. One problem with web components is that the barrier of entry is too high. Existing web components, for the most part, are not very user-friendly, and there are some technical issues with the specifications themselves as well.

In other words, web components are a good idea in theory, but the implementation is still lacking.

Let’s look at some other drawbacks to using web components.

Web components don’t follow native HTML behavior

Web components were intended to behave similarly to native HTML elements. That means developers should be able to control them using HTML markup, such as tags, relationships between parent and child elements (think <select> and <option>), and attributes — without having to write JavaScript.

In the case of most available web components, this hasn’t come true. You need to have stable knowledge of JavaScript to set up and configure web components through the belonging API and add all the dependencies they need. Lea Verou describes this phenomenon as HTML not being “treated with the appropriate respect in the design of these components.”.

In theory, it would be possible to create well-designed custom elements that fit with native HTML behavior. This simply doesn’t happen frequently in practice. Jeremy Keith summarized this problem in his conference talk, “Evaluating Technology,” back in 2017 (the landscape hasn’t gotten improved much since then):

“What I tend to see when I see web components in use is more like this where it’s literally an opening tag, closing tag, and all of the content and all the behaviour and all the styling is away somewhere else being pulled in through JavaScript, creating a kind of single source of failure.”

Issues with backward-compatibility and SEO

Obviously, if a web component doesn’t follow HTML design principles, you can’t add content for older or nonsupporting browsers, so people using those browsers won’t see anything on the screen.

Ideally, custom and standard HTML elements should be used together and complement each other. Custom elements are only necessary when there’s no corresponding standard element.

Say you want to create a horizontal tab element, for example. If you want to make it compatible with nonsupporting browsers, you can design it in a way that it works together with a standard HTML element, such as <p>, <section>, or <div>, depending on the type of content that goes into the tab:

<horizontal-tab>
  <p>CONTENT</p>
  <p>CONTENT</p>
  <p>CONTENT</p>
</horizontal-tab>

For lower-level compatibility, you could create another custom element for the tab items but still add the content via HTML. Introducing <tab-item> is unnecessary since you could store the internal content in a standard HTML tag. Here’s a real-world example of this solution.

<horizontal-tab>
  <tab-item>CONTENT</tab-item>
  <tab-item>CONTENT</tab-item>
  <tab-item>CONTENT</tab-item>
</horizontal-tab>

You can design it in a way that adds all the content via JavaScript. Again, the user of a nonsupporting browser will see nothing on the screen. Of course, you could use a polyfill, but that adds more complexity that won’t be worth it for many developers.

<horizontal-tab></horizontal-tab>

Moreover, web components that add content via JavaScript are not always indexed by search engines. This type of design affects SEO negatively.

Dropping HTML imports

Dropping the HTML import specification is another reason why developers are reluctant to use web components. HTML imports enable you to import modules without JavaScript using the following simple, beginner-friendly syntax:

<link rel="import" href="module.html">

Since browser vendors expected that ES6 modules would replace HTML imports with time, they decided not to implement the feature; Mozilla, Webkit, and Chrome all stopped considering adding HTML imports.

Currently, web developers use ES6 modules in place of HTML imports to package web components. This further adds to the complexity of a process that was intended to be easy and beginner-friendly.

Technical limitations of the web component specifications

As I mentioned earlier, specifications related to web components can be found at three places:

1. Custom elements
2. HTML templates
3. Shadow DOM

But, this is just one of the problems specs-wise. There are many other technical issues that you’ll encounter if you start developing a custom element.

Michael L. Haufe collected some of them in his excellent article, “The Criticism of Web Components.” The most troubling issues include the following:

• CSS pseudo-elements, such as :checked, don’t work with custom elements
• Standard HTML elements ignore custom elements if their behavior is related to each other — for instance, the standard form element ignores a custom input element
• Custom elements can’t extend higher-level standard elements such as HTMLButtonElement, but they need to extend HTMLElement
• ARIA roles have to be re-added to custom elements and also to their child elements, even if those are standard HTML tags with default ARIA roles (see more about this on the Salesforce Developer Blog)

These technical issues stem from the limitations of web components standards and have to be addressed using various hacks or extra code (that further increase complexity).

No central directory

It’s not easy to find web components. There’s no central directory or index, so you have to surf through the web to find what you need.

If you find more than one web component of the same type, it’s difficult to figure out which one fits your projects better, mainly because many web components lack good documentation.

UI libraries vs. web components

UI libraries, such as React, Vue, and Angular, serve the same purpose as web components: they make component-based frontend development possible. Even though they’re not native to web browsers (you have to add the libraries separately while web components use web APIs built into the browser, such as DOM and CustomElementRegistry), they have a huge ecosystem, good documentation, and many developer-friendly features.

So, it’s natural that many companies opt for these popular UI libraries rather than experimenting with web components — especially since it’s also easier to find developers with this kind of knowledge on the job market.

The future of web components

Even though the web component technology faces many problems, using web components still has some advantages.

Most importantly, while frameworks are coming and going (think Backbone.js, which has almost completely disappeared), web components are browser-native technologies. That means if you’re planning for the long term, you can future-proof your project by opting for custom-developed web components.

Many popular UI libraries also publish their elements as web components so you can use them in your projects in a framework-agnostic way — for instance, here are Angular components packaged as custom elements. This also shows that the creators of these frameworks count with web components in the long run.

There are some promising web components projects, all developed by big industry names, including Microsoft’s FAST components and Salesforce’s Lightning Web Components. In addition, Google still maintains the Polymer project ,albeit with a new component-based class.

If you don’t want to use someone else’s web components and would rather create your own, there are some open-source tools and resources, such as the Stencil.js web component compiler by Ionic (also used by Apple), the Open Web Components toolkit, and the Gold Standard Checklist for Web Components , that can help you follow best practices.

Given these developments, there is still some hope that web components will be adopted more widely in the future.

Conclusion

Overall, having access to more accessible, easier-to-use web components that resemble more native HTML elements would be a great advancement for frontend development.

To achieve this, developers of web components need to follow best practices, give more respect to the principles of HTML, create better documentation, and think about backward compatibility.

The web component standards also need further improvement to address both the technical limitations that make it hard to use custom elements with standard HTML, CSS, and JavaScript and the issues with accessibility and search engine optimization.

To stay in the loop, you can follow the latest news, issues, and discussions related to web components in the webcomponents GitHub repo maintained by the Web Incubator Community Group (WICG).