path: root/published/webdevat25p2.txt

The promise of the web sometimes outstrips the reality, but the reality is starting to close in on the promise in very exciting and revolutionary ways. 

Web developers have already shown that you can <a href="">crowd-fund features into web browsers</a> and thanks to a new set of tools coming soon to a web browser near you, web developers will be able to not just vaguely influence the direction of the web with crowd-funding and <a href="http://responsiveimages.org/">community groups</a>, they'll be able to directly add new features to HTML.

Right now the process of getting a new feature into HTML can take years. The process of moving from initial idea to draft spec to a feature actually available in web browsers is long, complicated and far more than any sane developer is ever going to undertake.

Critics of the web standards process are fond of pointing out some admittedly egregious examples of the snail's pace the standards process takes. For example, it took 17 years from the start of CSS to get widespread support for custom fonts in HTML (Internet Explorer 4 paved the way here, adding support for custom fonts way back in 1997. Sadly, it would be another 10 years before CSS added it back and other browsers added support). To put that in context a little bit, consider that it took the United States about eight years of concerted effort to put a man on the moon.

Yes, 17 years is astoundingly slow for something seemingly so simple. Even taking into account that much of that delay is related to licensing problems, it's still not a vote of confidence for standards bodies and browser makers as innovators. Part of the problem is that neither standards bodies nor browser makers are made up of web developers and there's often a considerable disconnect between what developers want and what standards bodies and browser makers focus their attention on.

Indeed, even when standards bodies are working like well-oiled machines (which they often are not), few would argue that they make for a good source of innovation on the web. 

Standardization is, by its very nature, a long drawn out process designed to achieve consensus, not drive innovation. In fact there's an argument to be made that taking 17 years to get support for custom fonts is a feature, not a bug. Except that no one argues that, because seriously, 17 <em>years</em>. For fonts.

While consensus is vital to the web and without web standards, we would not have the web we have today, if web standards were the end of the story there would be no innovation on the web. In fact it's the back and forth between developers and standards bodies that make the web a better place.

But web developers want to build new things when they think of them, not when standards bodies finally endorse them and browsers get around to shipping them.

The slow pace of new features on the web means the web is constantly playing catchup with proprietary platforms where new features come faster and more regularly. And for developers those new features make native platforms more appealing than working on the web. (Even if you were going to only support browsers that update every six weeks -- Chrome and Firefox -- you'd still be waiting an absolute minimum of 24 weeks for new features to progress from experimental builds to actual shipping features).

Luckily for the web there's a solution to the molasses-like pace of new features on the horizon. A collection of new tools referred to as Web Components promises to put the power of creating new features in the hands of web developers.

Web Components are actually not a singular thing. Rather, the Web Components specification is a catch-all for several interrelated tools designed to make it much easier for anyone to add new elements to HTML. Some of these tools, like the mysterious sounding <a href="http://w3c.github.io/webcomponents/spec/shadow/">Shadow DOM</a>, are already making their way into web browsers.

Others, particularly Custom Elements, which allow you define your own HTML elements and their behavior, are just starting to arrive. All of them will hopefully be available in all the major desktop and mobile web browsers in the next 12 to 18 months. 

Developers seem prone to hyperbole when talking about Custom Elements and Web Components more generally, and with good reason. Web Components are truly groundbreaking in that they allow web developers to create, package and reuse their own HTML elements. 

Perhaps the easiest way to understand the power of Custom Elements is to look at an example. Google has gone to great lengths to make it pretty easy to embed a map in a webpage and use some JavaScript to control it. However, with Custom Elements, Google could simplify the process even more by defining a new HTML element, say "<code>&lt;google-maps&gt;</code>".

Browsers would see the made up <code>&lt;google-maps&gt;</code> element and register it using the <code>HTMLElement</code> interface. The <code>HTMLElement</code> interface then allows developers to add methods and properties, in effect creating a per-element API. That means you can pass in attributes to control the element. So instead of needing to write a ton of JavaScript to set the center of our map, we could simple do something like this: <code>&lt;google-maps latitude="0" longitude="0"&gt;&lt;/google-maps&gt;</code> and the browser would display a map centered on Greenwich. 

I didn't pick this example at random. Thanks to Polymer, a library of polyfills that includes support for Custom Elements, you can use developer Eduardo Lundgren's <code>&lt;google-maps&gt;</code> element exactly as show above in any web browser today. 

Notice that while I started off talking about how Google could create a custom element, the example I just pointed to comes from an independent web developer. Anyone can create custom elements in HTML with Web Components (technically anyone can create new elements in HTML right now, without Custom Elements but there won't be any element-level API or other features that make Custom Elements actually useful). 

In the end, this may be the real power of Web Components -- they put developers on a level playing field with web giants like Google and with standards bodies as well.

That's by design. In fact, once you get past the really great encapsulation that Web Components enable, most of what's revolutionary about them comes down to the way they shorten the distance from developer idea to web standard. 

Part of the goal behind Web Components is to allow web developers to iterate on ideas before they become standardized. In other words, see how the web ends up using something new before you bother to start the standards process. When you do start the process you start with something that's already fleshed out, real-world tested and much closer to a consensus. This will hopefully create a more productive feedback cycle between web standards bodies and web developers.

Much of the effort behind Web Components comes from Google and Mozilla developers who put together a document called "<a href="http://extensiblewebmanifesto.org/">The Extensible Web Manifesto</a>" which reads: "In order for the open web to compete with its walled competitors, there must be a clear path for good ideas by web developers to become part of the infrastructure of the web. We must enable web developers to build the future web."

Never in the short history of the web have web developers had such power given to them. In fact, perhaps what's most remarkable about the web is that developers have created what we have today in spite of very limited input and control over the future of the web. We take tools like XMLHttpRequest for granted today, but these exist not because a standards body created them, but because web developers used them in creative ways that drove browsers to adopt support.

Now, with Web Component support on the horizon, developers will finally be first-class citizens when it comes to determining the future of the web.