Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Why You Should Care About Web Components

DZone's Guide to

Why You Should Care About Web Components

· Java Zone
Free Resource

What every Java engineer should know about microservices: Reactive Microservices Architecture.  Brought to you in partnership with Lightbend.

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.

Without web components

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.

With web components

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.

Microservices for Java, explained. Revitalize your legacy systems (and your career) with Reactive Microservices Architecture, a free O'Reilly book. Brought to you in partnership with Lightbend.

Topics:

Published at DZone with permission of Victor Savkin, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}