Welcome back! Web Components grow more popular every day. Why? They save time, money, and energy because they are reusable! And there are loads of other reasons that we'll cover in today's post.
Firstly, we cover the main benefits. Secondly, we cover the technical gains. Next, we do some myth-busting, and finally, we share a few closing thoughts. Are you excited already?
Posts in the Web Components 101 series
- What are Web Components?
- Why use Web Components? (this post)
- [Tutorial] How to create a Web Component? (/blog/web-components-tutorial-how-to-create-a-web-component)
Why use Web Components?
JavaScript frameworks offer lots of benefits:
- Save energy. Modern JavaScript frameworks are full of best practices, scaffolding tools, basic models, and industry standards. It lets us build and publish apps in no time. Above all, it allows developers to focus on real development, and not on the tools and architecture.
- Reusable code. Components built with a JavaScript framework are interchangeable (in applications using the same framework), and teams don't have to invent the square wheel twice.
- A common language for everyone. Using a JavaScript framework forms a shared understanding between developers. Everyone "speaks" the same, common language and is on the same page.
It's no surprise that 99% of all developers build apps with a (modern) JavaScript framework or library. And why should we prefer Custom Elements over our favorite framework? What problems does using a native component model solve?
(Brand) Consistency
Consistent applications offer user-friendly interfaces and have high growth rates. Inconsistent applications offer the exact opposite and threaten brand consistency instead.
Component libraries and Design systems improve brand consistency however only when fitted with all different tech stacks.
Web Components, with its web-standards-based APIs, is interchangeable between all tech stacks and JavaScript frameworks and libraries and gives the perfect technical base for brand consistency to all applications in a business.
Maintainability
Building sustainable and maintainable applications is one of the hardest challenges in Web Development. We create new versions when we copy code from one (part of a) application to another, and, as a result, we have to maintain indefinitely. Welcome to maintenance hell 🔥🔥🔥
Custom Elements are perfectly maintainable by one (team of) developer(s) and easily shared with others. The maintainers take care of the components, and the consumers can fetch updates automatically (e.g. with npm) while continuing their work, and 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 understandable, maintainable, and reusable apps. It is one of the hardest tests 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, and in the meanwhile, the user can profit from the changes automatically without the need of upgrading the code by hand.
Interoperability
JavaScript frameworks like Angular, React and VueJs are awesome! They have stuffed them with best practices, scaffolding tools, models, and industry standards, and let us build and publish an app in no time. But they aren't very interoperable, because they don't communicate with each other very well. This is because they all have various, non-interchangeable component models
Web Components are entirely based on web standards and are compatible with (or without) any JavaScript library or framework. As a result, that they are fully interoperable between frameworks and applications. It's now 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) because 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 make sense of the <div/> soup into plain, 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 Custom Elements. In other words, full encapsulation.
Web Components are perfectly compatible with any JavaScript framework of library
As mentioned in the first article of the series,, the support for Web Components from JavaScript frameworks and libraries is excellent and growing! They play nicely 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 them, and evolving web standards, with their flaws and limitations, are the main reason. I've seen some myths go around and now it's time to bust them!
Web Components are not server-side renderable (SRR)
Busted! Web Components are server site renderable since they are based on web standards. 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 introduced in the first article of the series, all JavaScript frameworks, except React are fully compatible. React supports them, 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 attach event listeners with addEventListener.
Web Components aren't accessible (a11y)
Busted! Folks think that Web Components are inaccessible because of the Shadow DOM because of the content cut from the main DOM. But as a matter of fact, this doesn't affect accessibility at all! The accessibility API exposes a11y information correctly, and its contents are perfectly accessible with screen readers.
Web Components aren't production-ready
Busted! Folks think Web Components aren't production-ready, because of their base on evolving web standards. False! All W3 standards are continuously evolving and that means that no technology would ever be production-ready, which is false.
Apple, Salesforce, and GitHub, for example, are all using them in production. Do you need more proof?
Closing thoughts about why we use Web Components
Even though 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, they are perfect for (brand) consistency, are maintainable, reusable, interoperable, and, above all, readable. They are also fully compatible with (or without) any JavaScript framework/library and offer full encapsulation.
The many myths add to the bad image of Web Components, and the reasons why folks aren't using them. But nothing stops you from using them to their full potential, because we busted most of them!