Are web components the future?
It's easy to be skeptical when you see people reinventing the wheel, but every iteration is a slight improvement on the previous attempt
“Any headline which ends in a question mark can be answered by the word no.”
Betteridge’s law of headlines is probably the knee jerk reaction to this post, and perhaps it’s apt in this situation too, but let’s not get ahead of ourselves quite yet. As they say, let’s start at the very beginning…
What are web components?
The description of web components from Google’s polymer library probably deserves repeating verbatim, because it cuts straight to the heart of what web components are, and why they might be worth using:
From <a> to <select>, elements are the building blocks of HTML. But modern applications have outgrown these built-in elements, forcing app developers to rely on JavaScript frameworks to provide dynamic, custom behaviour. The resulting apps are frequently complex and monolithic; a component developed for one may not work in another.
Polymer puts elements back at the center of web development. With Polymer, you can craft your own HTML elements and compose them into complete, complex applications that are scalable and maintainable.
The blurb from the other major player in this space, Mozilla’s X-Tag library is perhaps not quite as succinct, but it echoes the same sentiments.
Web components are the way forward to creating reusable user interface elements that can be easily embedded in any website with minimal overhead.
New or old? Widgets have been around while.
Does that all sound familiar? It should do. Attempts to this end have been done several times before; GWT, Dojo, Jquery-UI, Wijmo, the list goes on and on.
Yet, despite the proliferation of these javascript widget frameworks, light weight CSS frameworks like Twitter Bootstrap remain significantly more popular, and outside of the so called ‘business applications’, widget component libraries have never really gained any momentum.
The problem is that these javascript component frameworks all seem to stumble into the same issues as they scale to large deployments:
- They do not interact well with the existing CSS and javascript ecosystems.
- You cannot mix and match components from one framework with another.
- The style and image assets are typically ‘heavy’ to support all possible widgets.
- It’s difficult and technical to create or customize components.
…and one absolute game killer:
- Integrating new components onto an existing website is extremely troublesome.
These widget libraries are not unusable, and indeed many great sites have been build using them; but almost universally they require the entire site to be created with the widget library in mind from the start.
In a nutshell, javascript widget frameworks have never really been a blazing success.
Is it worth doing it all again with web components?
It’s easy to be skeptical when you see people reinventing the wheel, but every iteration is a slight improvement on the previous attempt, and this time, they seem to have got it right.
Web components use four new HTML5 javascript APIs that are working their way to the surface:
As the banner image by our awesome in house illustrator Curtis shows, by boxing up all of these disparate elements, a web component packages up into a single drop in file that runs in a completely isolated CSS context with zero side effects.
Integrating a web component into a website can be as simple as:
<html>
<head>
<link rel="import" href="elements/hello-world.html"/>
</head>
<body>
<hello-world/> <!-- A component! Wow! -->
</body>
</html>Embed Block Add an embed URL or code. Learn more
Specifically, the HTML5 custom elements allows any custom <TAG> to be expanded into a custom mini-DOM using the HTML5 templates, that exists in an isolated CSS context using the shadow DOM.
Significantly, the source for a component like this is a single file that contains human readable markup and CSS, along with javascript for custom behaviour:
<template id="hello_world">
<!-- The raw CSS styles are embedded into the component itself. -->
<style>
hello-world>div {
border: 2px solid #000;
}
</style>
<!-- This designer friendly template is rendered into the DOM. -->
<div>
<span>
This is a COMPONENT!
</span>
</div>
</template>
<script>
(function () {
var component_id = 'hello_world';
var component_name = 'hello-world';
var owner = document._currentScript.ownerDocument;
var tmpl = owner.getElementById(component_id);
var prototype = Object.create(HTMLElement.prototype);
// This callback is invoked when a component is created for
// customized javascript behaviour on a per component basis.
prototype.createdCallback = function () {
var root = this.createShadowRoot();
var clone = document.importNode(tmpl.content, true)
root.appendChild(clone);
};
document.registerElement(component_name, {
prototype: prototype
});
})();
</script>Since this is a single drop in file it is extremely easy to drop into an existing site, it’s extremely easy to take a copy and customize it and because it exists into an isolated CSS context without any javascript dependencies it has no side effects, meaning it can interact happily with any other web component from any source.
Web components are the next big thing…
Google and Mozilla are both actively pursuing web components and collaborating on the Polymer polyfill to support web components on older browsers.
It certainly looks like the the shiny glory of web components is going to be the next big thing, there’s just one tiny hiccup in that plan:
It’s mid 2014 at the time of writing, and broadly the statistics around seem to indicate that IE8 support, while continuing to fall, is still somewhere in the region of 5-10% of all web traffic, and somewhat higher in business contexts.
The big downside of web components is that there is no graceful degradation for older browsers; the web component flat out won’t be invoked at all, which means a completely broken site for older browsers, or two different sites; one for old IE and one for everyone else.
It might be fine for Google to say they don’t care about IE8 users; but not everyone has that luxury.
Specifically, in developing web content for business clients it’s often a struggle to even move past IE7, we could still be as far as two years away being able to move entirely past IE8 and abandon it completely.
So that leaves an awkward situation here a promising new technology is marching out, but not everyone gets to play with the new toys.
…and that’s not the only thing!
Unfortunately despite the best efforts of some of the smartest people on the planet at Google and Mozilla, there are also still a couple of very rough edges for web components.
They still don’t interact with the existing javascript and CSS framework ecosystem.
Since all the javascript and CSS are bundled inline in the web component document, there’s no immediate support for handling compile-to-javascript languages like coffee script or compile-to-css languages like Sass or Less.
A number of options are currently under consideration for resolving this, including the use of <link> tags to include external javascript and css files, but no firm decision has been come to, and going down this path breaks the ‘one file include’ paradigm.
Web components are not immediately suitable to minification.
As the number of components rises, so does the number of <link> tags in the document header.
Particularly for mobile websites the number of server requests can be a important performance concern, which is why javascript and CSS minification and concatenation helpers are typically used in production deployments.
However, since each web component is a distinct .html include, it’s not immediately trivial to either process the parts of component, or combine components.
Google provides the vulcanize tool to deal with this issue, but it seems like something of a work around for an issue that hasn’t been fully considered.
Web components don’t handle javascript dependencies
Unfortunately there does not immediately appear to be a way to create a web component that interacts with the existing javascript ecosystem using AMD.
As such, web components appear to be largely inline collections of 'adhoc’ scripts to perform well defined operations that existing javascript libraries already exist for.
Libraries like Polymer provide common boiler plate in a global context for their components to use, but it’s still quite common to see components like qr-code, using this pattern:
<script src="//cdnjs.cloudflare.com/ajax/libs/polymer/0.0.20130905/polymer.min.js"></script>
<link rel="import" href="src/qr-code.html">
<script src="src/qr.js"></script>
<div>
<qr-code data="hello world!"></qr-code>
</div>Notice the extra library arbitrarily dropped in at the top for ‘src/qr.js’.
Manually managing the javascript dependencies that a component depends on by adding them as separate external javascript tags completely abandons all the progress that has been made with javascript module systems.
So where does that leave us?
Web components are an evolving standard which continues to be worked on even now, they unfortunately remain practically unusable for the immediately foreseeable future.
With all the interesting things in them, that’s a pretty sad conclusion to come to, but realistically, that’s the situation at the moment:
- Without IE8/IE9 support they are unsuitable for many situations.
- The inherent limitations of the web component format are still not fully resolved.
- There is still limited or no support for existing frameworks (eg. Sass).
As Google writes in their Polymer FAQ:
Is the rest of Polymer production ready? We don’t think so, but if you’re the adventurous type you’re welcome to give it a try. Run the demos, play with the toolkit. Most importantly, join the mailing list and give us feedback!
Web components probably are the future of web development; but for the time being it looks like they’re going to stay there for most of us.
A completely lost hope?
Certainly not. As browser usage continues to shrink we’re rapidly approaching the time when we will no longer have to support IE8, and a lot of interesting technologies like Dart, canvas and web components can slide forth into mainstream use.
Although that’s still some time away, what we can do right now is start using the ideas from web components to build small modular javascript/CSS/html drop-in component-like libraries which can be ported into web components later on, and that’s something we’re actively looking into here at Hatchd.