“Any headline that ends in a question mark can be answered by the word no.” — Ian Betteridge
Betteridge's law of headlines describes most likely your response to the offensive headline of this article. I never understood the ongoing war between Web Components and JavaScript frameworks like Angular, React, VueJs, etc. Yet, combining the two could make the world of frontend development so much easier and more efficient.
Disclaimer: I know React is a library and not a framework, but for the purposes of this post I will refer to it as a framework.
It seems that many developers feel threatened by the thought of Web Components wiping out frontend frameworks. That won't happen because they are built to solve different problems.
“Most people who use React don’t use Web Components, but you may want to […].” — https://reactjs.org
It is a shame that Web Components are still going so unnoticed these days. In this article, I will tell you when you should use them and why they will play a significant role in the future of frontend web development.
What are Web Components?
Web Components are reusable client-side components based on official web standards and supported by all major browsers. They are an excellent way of encapsulating functionality from the rest of our code. Not only that, but you can reuse them in every web application and web page.
Web Components enable us to develop entirely independently of frontend frameworks.
The primary benefit of Web Components is that we can use them everywhere. With any framework, or even without a framework. — vuejs.org
How do they work?
Here's an example of how an autonomous web component can be defined:
class MyWebComponent extends HTMLElement {...}
window.customElements.define('my-web-component', MyWebComponent);
You can pass your element to any HTML page like this:
<my-web-component value="something"></my-web-component>
For more details on web components, check out this series of articles:
When should you use Web Components?
Imagine a company that has developed a highly complex web application using React. Several hundred developers are working on it full-time. They created their own internal React component library to have a robust set of ready-made UI components such as buttons, inputs, dialogs, and so on. That helps to minimize code duplication within the system, which is great!
As we all know, the software industry is one of the fastest-growing and changing industries. This is accompanied by many changes and innovations in Software Engineering. Assuming, next year, someone will release the ultimate frontend framework, which will overshadow any existing one.
More and more developers are adopting the new framework. Over the years, companies will use the framework for new projects, and some will migrate existing ones. React wouldn't be efficient anymore, and finding good React developers is getting more complicated and expensive.
Vendor lock-in refers to a situation where the cost of switching to a different vendor is so high that one is essentially stuck with the original vendor.
The company in our example would be "locked-in" to the inferior frontend library React. Switching to the new framework would be very expensive and may interrupt business operations. Every single frontend component of the application would have to be migrated to the new framework.
“Vendor lock-in is when someone is essentially forced to continue using a product or service regardless of quality” — cloudflare.com
What could the company have done to reduce the costs of vendor-lock-in initially?
The use of standards makes systems more tolerant to change. As you probably have suspected: The company could have created Web Components for their UI components. Even React itself is suggesting the use of Web Components in their official documentation:
Most people who use React don’t use Web Components, but you may want to, especially if you are using third-party UI components that are written using Web Components. — https://reactjs.org
While Web Components provide strong encapsulation for reusable elements that must be shared across multiple projects, React provides a declarative library that keeps the DOM in sync with your data. The two goals are complementary.
“As a developer, you are free to use React in your Web Components, or to use Web Components in React, or both.” — reactjs.org
You just don't need React to create a reusable button! Meaning, whenever you plan to have multiple projects with different technology stacks in which you need to share components, go ahead and build Web Components.
Why should you learn Web Components?
Escaping vendor-lock-in is one of many reasons why you should learn and use Web Components. Here are a few more reasons why you should definitely have a look at Web Components:
Web Components are widely used.
The chart below shows the percentage of page loads (in Chrome) that calls customElements.define
at least once.
You can see that more than 15 % of all websites, viewed in a Chrome browser, register at least one Custom Element. Compared to that and according to w3techs.com only 2.3 % of all websites use React.
Frontend frameworks support Web Components.
Earlier in the article, we already figured out that React supports creating encapsulated and reusable Web Components. Not only React but also Angular and VueJS are supporting this idea.
Let's have a look at Angular. Angular provides the @angular/elements
package which enables developers to transform a component into a Web Component quickly.
“Angular elements are Angular components packaged as custom elements […] “— angular.io
And also, VueJS is supporting Web Components via the defineCustomElement
method.
“Vue supports creating custom elements using exactly the same Vue component APIs […] ” — vuejs.org
You understand what is going on under the hook.
As we already know, many modern frontend frameworks support the idea of Web Components. Some of them, especially VueJS, are building on the foundation of web standards.
Knowing the three main technologies (Custom Elements, Shadow DOM, and HTML Templates) of Web Components will help you understand how your JavaScript framework does all the magic.
If you have worked with VueJS you are probably familiar with the scoped
attribute which you can pass to a style element.
<style scoped>
/* local styles */
</style>
The scoped
attribute will make styles of a VueJS component only apply to elements of the current component only. If you are familiar with the three main technologies of Web Components, you probably already know which technology VueJS uses here — the Shadow DOM.
“This is similar to the style encapsulation found in Shadow DOM.” — vuejs.org
Shadow Trees enable us to keep the markup and style of components separate from other code on the page to prevent mixing up the styling of different parts of the website. Check out this article to learn more about Shadow DOM:
It makes learning new frontend frameworks easy.
Many people say that if you master one programming language, it is easy to learn any other. The same applies to frontend frameworks.
During university, I have had the pleasure of learning the fundamentals of Web Components. Before that, I mainly worked with Angular. Today, I have worked with all three big frameworks — React, VueJS, and Angular.
The last one I had to learn was React. Due to my experience with Web Components and the two other frameworks, it was effortless for me to get started with React. In the end, it is always the same with a different syntax: You create components. You need to pass data up or down the DOM tree. You need to render some data.
Networking effect
Chances are high that you have used some kind of Material Design Framework. There is Angular Material for Angular, Vuetify for VueJs, and Material UI for React. And of course, there are plenty more. One might be a little bit better than the other. Still, each of them provides mainly the same reusable UI components like buttons, inputs, dialogs, etc. The implementation is always done with the corresponding framework.
Wouldn't it be nice we could all share our web components in a single unified web? We could pick the best UI components without caring about frameworks. That would make us independent from JavaScript frameworks. Using Web Components would heavily reduce the costs of changing between them.
There are already a few Web Component libraries maintained by companies like e.g., Google and SAP:
Material Web Components (MWC): Collection of Web Components following Google's Material Design principles.
Polymer Elements: Google's Polymer library lets you build encapsulated, reusable Web Components that work like standard HTML elements
Vaadin Web Components: Vaadin components is an evolving set of high-quality user interface web components
OpenUI5: SAP's rich set of enterprise-grade reusable UI elements driven by a lightweight framework
Unfortunately, I think those components are not as mature as for example React's Material UI. The more developers are contributing to this, the better it will get.
Learning Web Components is easy.
Learning Web Components is easier than you might think. They consist of three main technologies:
Get started by following this series of articles:
Assuming you are using a library like Lit or Stencil, development is not that different, let alone more complicated than using a modern JavaScript library. Have a look at this series of articles to build your own Medium Blog portfolio with Web Components.
It will start by using plain HTML, CSS, and JavaScript. After that, it will use the Lit library to make development easier.
Final Thoughts
Web Components will not replace frontend frameworks in the near future. Nevertheless, they can enhance those frameworks by replacing their component layer with a native and uniform solution.
Thanks for reading!
Want to learn more about how I scaled my Chrome Extension to almost 100,000 users as a solopreneur? Subscribe to my stories or follow me on LinkedIn and Twitter.
If you read a lot online, make sure to check out my Chrome Extension loved by 90,000+ active user - it's free: