Why You Should Care About Web Components

Since there is no standard way to define a component, every framework has to invent its own, and JavaScript is a flexible enough language to allow that. Unfortunately, this results in fragmentation: components built using different frameworks do not interoperate with each other. Web components are a set of specifications solving this problem.

Two Date Pickers

Let’s take a simple component that you are likely to see in pretty much any application - the date picker component.

If we are to build this component in Backbone, the result might look as follows:

var datePicker = new DatePicker({el: el, format: 'yyyy-mm-dd'})

Where DatePicker extends Backbone.View.

The same component written for an Angular application is going to have a very different API:

<data-picker format='yyyy-mm-dd'/>

Where data-picker is a directive.

Though both the date pickers look and behave exactly the same, their implementations and APIs are drastically different. They do not conform to a common interface. Which means that if you are a lucky maintainer of several applications written with different frameworks, you will have to maintain multiple copies of the date picker component. Needless to say, this is not ideal.

Web Components are the Solution

This problem is due to the lack of a solid foundation all frameworks can be built on top of. Web components are such a foundation.

Web components are a set of specs that enable developers to build reusable components. They bring great things such as Shadow DOM, HTML imports, custom elements, and the template element. As a framework developer you directly benefit from these advancements because the browser will take the responsibility for a bulk of the work you have to do right now.

As an application developer you may not see direct benefits. Yes, “Shadow DOM” sounds really cool, and the idea of frameworks’ implementations being cleaner is nice too. But practically speaking you already can define component-like things in all major frameworks. The benefits get obvious, however, when you start thinking about the ecosystem of your applications, or the overall JavaScript ecosystem.

The Fragmentation of the Ecosystem

Since there is no standard way to define a component, every framework has to invent its own. This results in fragmentation: components built using different frameworks do not interoperate with each other.

Web components specs provide a way to define UI elements that can be used in any application, regardless of the framework it is written with. In addition, these custom UI elements work like built-in divs and inputs. So they can be used with any framework, as long as it works with HTML. In the example above, we would have one date picker component that we can use with both Angular and Backbone, even though both have no support of web components at this point.

Wrapping Up

The current situation, when a component written in, for example, Backbone cannot be used in any other context, is hurting the JavaScript ecosystem. Web components are a remedy for this problem.