“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:
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.
- 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.
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.
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>
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.
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 where 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.
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.
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.
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’.
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.
Interested in working with us?
Whether you have a clearly defined product brief or you're not sure wherein the problem lies, drop us a line for a no-pressure chat about where you are at and how we might help.