Web Components 101

Is it possible to abstract low-level constructs of HTML to define high-level semantic components? Yes!

Over the past few years a lot of people have been trying to rethink the way the web can/should be used. Currently, front-end developers find themselves in the often-frustrating situation of having to build complex websites with HTML–which can often be a fairly blunt tool–on top of the clunky foundations of Jurassic-age web browser limitations.

Let’s start simple to illustrate the problem: Imagine that you are developing a website for airline tickets. As you are working, you decide that you would like to include a calendar in your webpage. Unfortunately, there’s no quick and easy way to create a calendar, using HTML. Instead, you will have to employ a variety of different elements to express this single concept. And if you need another calendar on the same page, you would have to repeat all those elements, and so on, for as many iterations as are needed.

There should be a simpler way to create something as simple and common as a calendar. And in fact there is. There are many 3rd-party libraries, (such as jQuery plugins), which can implement a calendar for you, but although these resources may save on coding time, at the end of the day they will add up to the same unwieldy mess of HTML elements in the page. The problems of coding while being limited to low-level elements are quickly compounded as ideas become more complex.

But let’s pause for a moment: How about this — once we conceive of ‘calendar’ as a distinct concept, what if we could code calendar as a single element in HTML? Wouldn’t that be great?

In more general terms: is it possible to abstract low-level constructs of HTML to define high-level semantic components (such as calendars)?

Yes, it is possible! Or at least, it will be possible soon enough with Web Components.

So what exactly are Web Components? Let’s drink it from the source, aka W3C specification for Web Components:

The component model for the Web (also known as Web Components) consists of five harmoniously interacting pieces designed to enable Web application authors to define widgets with a level of visual richness and interactivity impossible to achieve with CSS alone, all with an ease of composition and reuse not possible with today’s existing script libraries.

The five pieces, at a glance, are:

  1. Templates, which define chunks of markup that are inert but can be activated for use later.
  2. Decorators, which apply templates based on CSS selectors to affect rich visual and behavioral changes to documents.
  3. Custom Elements, which let authors define their own elements, with new tag names and new script interfaces.
  4. Shadow DOM, which encapsulates a DOM subtree for more reliable composition of user interface elements.
  5. Imports, which defines how templates, decorators and custom elements are packaged and loaded as a resource.

These five pieces make it easier to make better things. Take our calendar example. Basically, a Web Component for a calendar would reduce all that HTML clutter to one, beautifully clean line of code:

<x-calendar chosen="2013-06-09"></x-calendar>

(This is actually an existing open-source calendar web component, available at https://github.com/x-tag/calendar.)

As you can see, this encapsulated code is more capable of efficiently and meaningfully representing a high-level component such as a calendar. We no longer need to deal with low-level elements such as divs or spans, now that they have been internalized. It’s cleaner, and easier to maintain.

Want to know how to use and develop a Web Component? Stay tuned on my next article about Web Components!

Originally published at www.avenuecode.com/code-highway on September 15, 2014.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.