Companies understand better than ever the importance of consistency to build a relationship of quality with their users. To help them do that, we design component libraries and branding style guides that attempt to scale but rapidly hit certain limitations.
Standards have failed to provide us with ubiquitous, practical and portable ways to solve a simple question: “how do I reuse UI components across all my sites?”.
We see a proliferation of projects trying to solve the component problem in slightly different ways, using various languages. When we build on top of one of these technologies, it is at the cost of opting into a non-standard world, offering no guarantees of lasting value.
What if web standards could help us solving that problem? And yes, “you can already solve it today with JavaScript”. I’ll get back to that.
The web is a beautifully diverse ecosystem: simple HTML documents, single page applications, CMSs, WordPress blogs, hosted sites, Intranets (including Salesforce applications…), webviews… but most of all, we have no idea what we will build our future products with.
How do we enforce consistency across current and future environments?
It seems today the cost of consistency unfortunately is… re-building the same piece of UI for each platform. This of course leads to more technical and design debt. This is a massive waste of our time.
This is where I’d like to answer the argument that “we can already solve it today with JavaScript”:
We should be tired of re-building our components for each new version of Angular, that we ported from Rails, and might transition to React.
We need the tools to solve this problem in future-friendly ways.
The idea of Web components was introduced in 2011 by Alex Russell, and since then the web community has discussed the concept a lot (127,000,000 results on Google Search for “web components”). Despite this interest, browsers haven’t fully implemented Web Components nor agreed on a spec yet; and as far as I know, no major actor has used them in production on large websites.
We’ve all been waiting for browser vendors to agree on an implementation before even thinking about using Web Components in production.
Thankfully, the wait is almost over: a first version of the Web Components specification is coming this year. Note that this v1 is pretty barebones and won’t bundle all of the Web Components features you may have heard of over the past 4 years. To know more about it, I recommend this article by Wilson Page: The state of Web Components.
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.
Competing implementations were very confusing for developers and paralysed progress instead of encouraging innovation. This v1 spec will have the expected impact as it becomes an agreed, shipped and usable standard in all major browsers.
Let’s get back to the benefits Web Components will bring to our users…
How is implementing Web Components going to impact user experience of the web? It will probably take years, and a lot of efforts for this process to mature. I broke it down into 5 steps:
We are seeing initiatives being taken already, but allow me to predict a few more using my psychic powers.
Most of all, we need large companies to lead the way and give confidence to smaller ones, by rolling out user-facing products using Web Components.
Google, Mozilla and IBM already use Web Components, and their code is open source (Polymer Elements, Gaia, Deliteful). I hope to read about how it helped them deploy UI components in multiple environments to achieve design consistency.
Bootstrap, Foundation and other HTML/CSS/JS frameworks will also transition and make Web Components ubiquitous to all web developers.
New Grunt and Gulp tasks will help integrate Web Components in current apps without sacrificing performance. We can already use vulcanize to concatenate multiple HTML imports into one file.
Module loaders and bundlers (WebPack, jspm…) will adapt to consume a standard type of components, making it easier than ever to build highly performant, complex web applications.
Google is looking at plugging Web Components into Angular 2.0 using Polymer 1.0. Stay tuned, watch Polycasts on Youtube. We’ll also see React, Ember and Knockout interface with Web Components in a not-so-distant future.
I can’t wait to see WordPress themes using Web Components, and maybe witness something that’s impossible at the moment: shared UI elements between WordPress, Drupal, Ghost…
Ultimately, components will be shareable across all of our websites.
When they don’t need to re-build and maintain duplicates, teams can focus on refining existing components. Imagine teams iterating on shared components, rolling them out to all users at the same time, no matter what frameworks their sites are built with…
With Web Components, the unprecedented speed at which we can develop, test, and improve features will be a huge benefit for the user experience.
This is why Web Components will make the web a better place for our users… And I don’t know about you, but building a better web sounds pretty exciting to me.
