The big deal about web components

I made my big Twitter announcement yesterday about finishing my book on JavaScript frameworks. After spending months diving into various communities, idiosyncrasies, and development philosophies of frameworks, I’ve learned at least one big thing about the next revolution in JavaScript development: you need to be aware of web components. [As for the book, expect more big announcements next month, a book with lots of sample code and tour-de-frameworks.]

The problem that nearly every JavaScript framework has solved time and time again is data-binding. How do we attach behaviors and data to a UI. In Backbone, you assign events; in Angular, you build directives, in Ember, components

Now, these frameworks do lots of other things, there are lots of other very repeatable tasks in application development (routing, history, controllers, etc.), but data-binding has long been a great beast to deal with.

Web components will be the solution to the data-binding problem. This is a hyperbole you might’ve heard more often as people are catching on to the excitement. I really believe this is true.

Of course, the problem now is that new web APIs take a long while to implement, and back support for browsers is extremely difficult. So don’t toss out your Marionette app just yet. This is the technology to watch, not the technology you can yet use (well, more on that later).

But wait. What’s a web component?

The most classic example of web components is the humble <select> tag.

 

Ah, the humble select tag. A tag that when you provide <option> elements inside it, it knows exactly what to do with them, you can access its value in a logical way from the DOM API, and it just workstm.

Custom elements are just one part of the proposal however; React, for example, is leveraging Shadow DOM in its library. CSS Tricks has a good (and recently updated) long read on web components, and here’s a deck from a Googler with examples (if you view in Chrome Canary, of course)

So what is around today?

Polymer (from Google) would have you use web components today using polyfills, and they have a framework built on top of that capability (although their branding has changed recently from framework to focus on the polyfills). X-Tag is the corresponding library based on web components from Mozilla, Brick being the framework like Polymer.

These are great options, however, since web components are a new spec, there’s a very fast pace, and things can and will change differently than you might expect.

Will some things be different than you like? Definitely. Will it take a long time to implement? Yes, of course. Gettting any spec adopted is a grossly undervalued process. Browser vendors are working together and also competing on the specs they want to prioritize.

I expect web components to continue to move rapidly, and obviously Google is putting a big line in the sand that they’re on board. There is of course the risk that like other certain APIs, that there’s a lot of excitement, but little innovation. I really don’t think/hope that’s not the case with web components. These are the tools that can change how we build JavaScript applications.

In closing, I leave you with a gif tag of Tina Fey and Amy Poehler high fiving.

Tags: , , ,

One Response to “The big deal about web components”

  1. Sheelah April 3, 2014 at 7:43 pm #

    W00t.. Congrats on the upcoming book, Pam!

Leave a Reply