The way that languages in the web platform evolve are in direct response to the pain caused by complexity. Pain is generally a bad thing and so it’s with better patterns and platform primitives that we can ease some of this complexity in the browser. Complexity on its own can take lots of forms, but when we look at the landscape of how developers have been building for the web over the last few years, common patterns can be one the most obvious things worth considering baking in solutions for. Layering the platform as part of the extensible web manifesto has been hugely helpful in making this possible.
<audio> tag) will be given to you by the browser but others like
<slide-show> will be custom elements provided by UI libraries or you can write it yourself. As the layer we’re using for composability is the DOM using attributes for our APIs, our elements will be significantly more interoperable than they’ve been in the past.
Imagine a future where elements or components written with different libraries can be used together with a level of ease.
One of the opportunities Web Components introduce is a chance to re-think and re-purpose existing best practices. If you’ve read my large-scale JS patterns write-ups of old, you may have gone on to craft systems using a componentization model for re-use, an event bus for inter-component communication and facades for abstracting away implementation detail behind an API. These ideas are still very much relevant today and I see them being evolved for a Web Component world through solutions like Polymer – polyfills and sugaring for this world and X-Tag. Polymer already has good support for message passing between elements and an API driven by element attributes is technically already a facade. We will also see much evolve through existing MVC libraries like Ember and Angular, as they look to embrace custom elements. Keep in mind, Web Components are not a silver bullet and the engineering best practices we as a community have strived for over the past few years will continue to be necessary:
When creating Web Components, keep in mind:
☑ Docs & Testing
— Addy Osmani (@addyosmani)
HTTP 2.0 is also going to be important for the future, bringing the promise of a decreasing need for concatenation, inlined images or styles. With push support, the server could know about dependencies being requested and smartly push dependencies when you require a specific element to be imported.
The web is slowly growing up and each step we take towards lowering complexity is ultimately a good thing. Even if rebuilding your application using the new and shiny isn’t an option just yet, at minimum continue to design your current path using reusability and composability in mind. This will make a transition in the future, when you are ready, a more pleasant experience.
Where to go from here
Eric Bidelman, Rob Dodson and other pioneers have authored some fantastic 101 articles about the underlying technologies that form Web Components worth reading. The community have also begun fleshing out best practice ideas around element authorship which serve as a good sanity check for components written with and without Web Components.
With special thanks to Dimitri Glazkov, Dominic Cooney, Alex Russell, Dave Herman, Yehuda Katz and the countless others who are helping us get a saner platform for tomorrow. Thanks also go to Sindre and Pascal for their reviews of this article.