Web Components 101: Why use Web Components?

Welcome back to the Web Components 101 Series! We're going to discuss the state of Web Components, provide expert advice, give tips and tricks and reveal the inner workings of Web Components.

In this article, we'll explain why we're so excited about Web Components and why you want to use them. We also do some myth-busting along the way. Are you excited already?

About the author

Stefan is a JavaScript Web Developer with more than 10 years of experience. He loves to play sports, read books and occasionally jump out of planes (with a parachute that is).
☞ If you like this article, please support me by buying me a coffee ❤️.

Posts in the Web Components 101 series

• What are Web Components?
• Why use Web Components? (this post)

Why use Web Components?

JavaScript frameworks offer lots of advantages:

• Save energy. Modern JavaSCript frameworks are packed with best practices, scaffolding tools, paradigms, and industry standards, which enables us to build and publish an app in no time. It enables developers to focus on actual development instead of the tools and architecture.
• Reusable code. Components built with a JavaScript framework are interchangeable (within applications using the same framework), so teams don't have to invent the square wheel twice.
• A common language for everyone. Using a JavaScript framework generates a common understanding between developers. Everyone "speaks" the same, common language and is on the same page.

It's not surprising that almost every JavaScript app is built with a (modern) JavaScript framework or library, so why should we use Web Components instead of using our favorite framework? What problems does providing a native component model solve?

(Brand) Consistency

Consistent applications offer user-friendly interfaces and have high conversion rates. Inconsistent applications offer the exact opposite and undermine brand consistency. Having your apps split up into component libraries or a Design System, improves brand consistency but if and only if they are compatible with all different tech stacks.

Web Components, with its web-standards-based APIs, is interchangeable between all different tech stacks and JavaScript frameworks and libraries and provides the perfect technical base for brand consistency throughout all applications.

Maintainability

Building sustainable and maintainable applications is one of the hardest challenges in Web Development. Code is continuously copied from one (part of the) application to another, essentially creating new versions that have to be maintained indefinitely, which results in maintenance hell.

Web Components can be maintained by one (team of) developers and shared with others. The maintainers take care of the components, while the consumers can fetch updates automatically (e.g. with npm) and continue their work without the fear of maintenance hell.

Reusability

Keep It Simple Stupid, and Don't Repeat Yourself are the mantra's that we keep repeating and is a key part of building comprehensible, maintainable, and reusable apps. It is one of the hardest challenges in web development. With Web Components, we're solving this by defining markup in JavaScript. The author is free to change the HTML, CSS, and JavaScript, while the consumer can benefit from the changes automatically without the need of upgrading the code manually.

Interoperability

JavaScript frameworks like Angular, React and VueJs are awesome! They are packed with best practices, scaffolding tools, paradigms, and industry standards, which enable us to build and publish an app in no time, but aren't very interoperable - they don't communicate with each other very well. This is because they all have different, non-interchangeable component models.

Web Components are completely based on web standards and are compatible with (or without) any JavaScript library or framework. That means, that they are completely interoperable between frameworks and applications. It now becomes possible to support multiple applications with UI components from a single codebase (Design Systems and mono repositories).

Readability

The most important audience for our code is humans (ourselves and other people), as we are the ones who will make or break the program in the future. Unfortunately, this doesn't always resonate and many HTML pages end up in an expressionless, and unreadable <div/> soup, like Google's Gmail page:

Web Components allows us to organize the <div/> soup into comprehensible, readable, semantic-friendly code by creating custom elements wherever we see fit. Here's an example of how it would look like:

<google-mail>
  <mail-list>
    <mail-item from="john.doe@company.com">
      <h2>Hello World</h2>
      <article>
        <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</p>
      </article>
    </mail-item>
  </mail-list>
</google-mail>

Full encapsulation

The Shadow DOM allows web browsers to isolate DOM fragments. It means that we don't have to worry about styles and logic leaking to and from our Web Components. In other words: They are fully encapsulated.

Web Components are perfectly compatible with any JavaScript framework of library

)

As mentioned in the first article of the Web Components 101 Series, the support for Web Components from JavaScript frameworks and libraries is excellent and growing! Web Components can be used with:

• Angular
• AngularJs
• React
• Vue.js
• Svelte
• Vanilla JavaScript

Busting myths about Web Components

Why not use Web Components? There are a lot of myths about why not to use Web Components. The main reason is that they are built on evolving web standards, which have their flaws and limitations. I've seen some myths go around and now it's time to bust them!

Web Components can't be server-side rendered (SRR)

Busted! Since Web Components are based on web standards, they can be server site rendered perfectly. It might be hard to do if you build a solution from scratch, but libraries like SkateJs and Stencil will do all the heavy lifting for you.

Web Components don't work with JavaScript frameworks/libraries

Both true and false. As mentioned in the first article of the Web Components 101 Series, all JavaScript frameworks, except React are fully compatible. React supports Web Components, but passes all data to Custom Elements in the form of HTML attributes. For primitive data this is fine, but the system breaks down when passing rich data, like objects or arrays. Developers will need to reference their Custom Elements using a ref and manually attach event listeners with addEventListener.

Web Components aren't accessible (a11y)

Busted! The main reason why folks think that Web Components aren't accessible is that HTML content is included in the Shadow DOM and not the main DOM, but in reality, this doesn't affect accessibility at all! The a11y information is exposed correctly through the accessibility API and screenreaders can access content in the Shadow DOM without any difficulties.

Web Components aren't production-ready

Busted! Folks assume that because Web Components are built on evolving web standards, they aren't production-ready but that's not true! All W3 standards are continuously evolving and that means that no technology would ever be production-ready, which is nonsense.

Besides that, Apple, Salesforce, and GitHub are all using Web Components in production. Do you need more proof?

Closing thoughts about why we use Web Components

Although JavaScript frameworks and libraries offer developers many perks, they have their drawbacks as well and this is where Web Components can fill the gap perfectly. Based on web standards, Web Components are perfect for (brand) consistency, are maintainable, reusable, interoperable, and readable. They are also fully compatible with (or without) any JavaScript framework/library and offer full encapsulation.

Many myths account for a negative image of Web Components and why folks aren't using them, but most of them are busted and nothing stands in the way of you using their full potential!