The Web Components project, led largely by the Google Chrome development team, aims to help solve a simple problem: Building Web applications is more complicated than it used to be. Worse, it's more complicated than it should be.
Modern Web apps have rich, interactive UIs, driven largely by client-side code. Today we generally build such UIs using JavaScript frameworks and UI toolkits, such as Dojo/Dijit, jQuery UI, and YUI. That's both good and bad. It's good because it means it's now easier to build rich Web UIs than ever before. It's bad because it needlessly shifts the balance of control over Web development from designers to programmers.
In the old days, we chuckled at newbies who talked about "HTML programming," as if writing markup made you a programmer. But to use a tool like Dojo or jQuery, that's really what you have to be. To create a pop-up dialog box using one of these toolkits, for example, you wouldn't just describe it, as you'd do in HTML. You'd probably instantiate a Dialog object, set some parameters that control how it will display, then tell it to insert the right elements into the DOM -- like a programmer. From the Semantic Web perspective, it means a lot of Web content is effectively hidden. Search crawlers and other JavaScript-disabled clients can't see it.
It also erects a barrier between Web designers and the relatively new category of dedicated client-side JavaScript developers. Once, Web designers could write some HTML and CSS and end up with a functioning UI. Now they're forced into the old model of gathering requirements, writing them down, handing them off to programmers, and seeing what comes back.
"That's actually a regression," says Google's Alex Russell. "We've regressed from how we'd like to be building apps. And it's worth acknowledging that we have failed, and that we would like to do better."
The components of Web Components
At the core of this idea is a new HTML element called a Template, which contains markup that gets inserted into the DOM but not displayed. Once it's in the DOM, you can activate a Template as many times as you want to make as many visible copies as you need -- like creating objects from a class.
What is a Template good for? For one thing, it can be used to create a Decorator: a complex package of styles that you apply to an element using CSS. It's much more powerful than plain CSS because in addition to modifying CSS attributes, it can insert blocks of markup and even script.
For example, your markup might contain a single word of bare text. Apply a Decorator, and suddenly you've changed its font, size, color, and positioning. Better still, a button has appeared next to it that comes prewired with an event handler.
Web Components also allow you to define custom HTML elements that extend existing elements. For example, you could create a subclass of the button element that has special properties. The Component that provides the custom button would include a constructor to wire each instance of the button with the appropriate JavaScript. There's no need to mess around with ID attributes and attach scripts by hand.
Another powerful Web Components concept is the Shadow DOM, which is like regular DOM, only it's hidden in the shadows. Its main purpose is to encapsulate the DOM of Web Components so that developers can't break them by fiddling around with a page's master DOM. It also exposes attributes of elements that you couldn't otherwise access. For example, you can use the Shadow DOM to change the look and feel of built-in widgets like sliders and scrollbars using ordinary CSS and markup, without resorting to JavaScript.
What can it do today?
If you want to experiment with them as they exist today, the place to start is Google's bleeding-edge, experimental browser Chrome Canary. It's for tinkerers only -- like the proverbial bird in a coalmine, it's prone to sudden death. But it won't interfere with your current browser; you can even install it side by side with a stable Chrome build.
You'll still probably need to enable some flags to get the Web Components demos working, and not every proposed feature is currently available. Remember, the project still in its early phases. Your best bet is to follow its page on Google+ for the latest updates and information.
Other browsers can't do anything with Web Components yet. But there's hope, in the form of another neat concept that's gaining traction with browser developers: polyfills. Essentially, a polyfill is code that provides support for a Web specification that you expect the browser to support natively in the future.
Polyfills have already been used to enable support for HTML5 features in older browsers. Now Google is working on a polyfill that will make at least some features of Web Components work on today's rendering engines.
In fact, one way to look at Dojo, jQuery, and similar toolkits is that they were early polyfills for some of what Web Components aim to do. "The way I like to think about this is that the toolkits that we've got now ... are a to-do list for the browser vendors," Google's Russell says. If Web Components become a standard, cross an item off that list.
This article, "Web Components: New hope for Web designers," originally appeared at InfoWorld.com. Follow the latest news in programming at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.