Why You Should Care About Web Components
Join the DZone community and get the full member experience.
Join For FreeSince 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.
Published at DZone with permission of Victor Savkin, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Trending
-
Integration Testing Tutorial: A Comprehensive Guide With Examples And Best Practices
-
Building the World's Most Resilient To-Do List Application With Node.js, K8s, and Distributed SQL
-
Five Java Books Beginners and Professionals Should Read
-
Why You Should Consider Using React Router V6: An Overview of Changes
Comments