Web Components Are Awesome

Component-oriented design has a long history…

Web Components are awesome, because component-oriented architectures are a proven model for interaction design. (For example, the two major mobile operating systems are arguably component-oriented.) Also because they are being defined as part of an open standard, and, as such, will enjoy ubiquitous support from browser vendors. In short, they’re a long overdue part of the Open Web stack. Unfortunately, the “Web is broken” angst plagues Web Components, just as it does every other part of the Open Web. We’re here to help.

Atavist

Let’s start with the story of Atavist. Atavist made their mark as a native iOS app. According The MIT Review, Atavist was “what Apple’s iBooks Author program should have been.” As such, they seem like they’d be on the native app bandwagon, right?

Nope. Recently, Atavist completely rebuilt their platform on Polymer. Here’s what the founder of Atavist, Evan Ratliff, claims about the new version:

At a basic level, it allows someone who is not a programmer to create a story online that looks beautiful.

Try out the app and decide for yourself.

Rapid Evolution

The Web is, by far, the most widely-used applications platform in the world. We’ve been building applications that run in the browser for a long time. And it’s continuing to evolve rapidly, benefiting from billions of dollars worth of combined investment from the likes of Google, Apple, and Microsoft. And—unlike alternative platforms—no one vendor controls it. There’s no lock-in and no switching costs.

There are a diminishing number of cases where it’s either technically impossible or prohibitively costly to reproduce a given feature of a native app. And maybe one of those is critically important to you. But you may want to double check before you decide you’ve just got to have that native goodness.

Last February, Flipboard boasted about reaching 60 FPS using Canvas. The motivation was the need for smooth-scrolling, which ironically became available in Firefox right about the same time. So if you’re basing your assessment on a bad experience you had in, say, 2010—or, even last February—well, things have changed.

And the emergence of a viable, standards-based component model is one of the biggest changes of all. One of the advantages of native development in the past was the lack of a component model in the browser. That made it difficult to reuse code and build apps that conformed to common look-and-feel. However, that’s changing now, thanks to Web Components.

The Web Components Standards

Web Components aren’t a framework or a cool idea. They’re defined by a suite of widely support W3C standards. Those standards are being actively refined and improved. The missing parts of the implementation are provided by a 32KB polyfill. (And for what it’s worth: polyfills are not some sort of awful hack or red flag. In fact, they’re precisely the same strategy JQuery and other libraries have been using for the better part of a decade to deal with emerging standards.) There are now at least 4 libraries for building Web Components: Polymer, XTag, Bosonic, and Skate.

An attendee of a recent panel on Web Components concluded:

The goal of the v1 isn’t to solve every problem, it is a contract between browser vendors: they will implement it. As a developer, it finally sounds like a green light.

I think that’s about right.

Polymer

Polymer itself offers one of the most complete component libraries available using any technology or platform, including native APIs. As of the 2015 Google I/O, Polymer is “production ready”—the implication being that, you know, Web Components are totally fine for you to use right now.

Planning For The Future

Web Components aren’t flawless. They won’t solve all our Web development woes. The standard itself is still a work in progress. But you can actually build things with them today. And you should be planning to use them in the future.