Web Components: What You Need to Know in 2015

Web Components are a collection of emerging web browser standards that are on a path to significantly change the way we develop UIs of web applications - a paradigm shift in web development. With polyfills already available in all modern web browsers, and full native support in Google Chrome, now is the perfect time to learn how you can benefit from using Web Components in your next project. In this article, you will learn about Web Components basics, available frameworks, Custom Elements, as well as challenges and applications associated with this new technology. After reading this article, developers will have enough background information to begin dabbling in Web Components.

What are Web Components and can I use them?
To a growing number of developers, the web browser is a first choice platform for building an application. However, as application complexity grows, a typical web-based application may suffer from browser and library incompatibilities, buggy and inconsistent UI or overall sluggishness.

Web Components are a fresh take on the abstract, declarative, cross-browser model of building applications from reusable pieces of code. In essence, instead of tangling your application with thousands of lines of JavaScript, you are now able to create applications by choosing from hundreds of fully styleable, single-purpose custom HTML tags, which are loaded on-demand, use browser DOM to integrate with rest of your app, and gracefully degrade when needed.

Image by the author. Icons by WebComponents.org (CC BY SA 3.0)

It is clearly in Google's agenda to make the web browser a compelling alternative to the desktop for building applications in the 2010s. This is probably why the company is leading the effort to set standard specifications of the Web Components stack, namely Shadow DOM, Custom Elements and HTML Imports and the addition of the <template> tag to HTML5. The three specifications have been at work since 2012 and bear the Editor's Draft status in W3C, while the latter (<template> tag) has made it into the final revision of HTML5, which received a W3C recommendation status on October 28, 2014.

The role of the four specifications is as follows:

• HTML Templates allow developers to define reusable chunks of code. There are no more hidden DIVs, markup disguised as <script type="text/template">. The specification does not go that far to define a template engine so you still have to use JavaScript if you need to mix the template body with content.
• Shadow DOM defines an encapsulated, hidden substructure in DOM that does not interfere with the outer world. You are free to use any IDs, CSS class names and style sheets as well as JavaScript to define custom behavior. Shadow DOM can also distribute nodes from the outer DOM.
• Custom Elements are a way to define your own HTML tags with observable attributes. You can now have a consistent, easy-to-use HTML API for sophisticated UI elements that keeps the details of their implementation in Shadow DOM. Custom Elements can extend existing elements.
• HTML Imports are the solution for on-demand loading of Custom Elements and HTML Templates. You can recursively define HTML Imports in HTML Imports, which allows for effective dependency solving. HTML Imports are subject to browser caching, so one import will not be loaded more than once for a web page.

While on the specification side, Web Components must be referred to as a work in progress, and that work goes hand in hand with the actual implementation in Google Chrome and Opera. Since version 36 of Google Chrome (released August 26, 2014), all Web Components features are implemented and enabled by default. Mozilla is actively following, with parts of Web Components also natively supported. Other browsers (IE11, Safari) rely on using a polyfill script called webcomponents.js (recently renamed from platform.js), which is maintained by Google.

Future of frameworks with Web Components: Adapt or die
Google is heavily investing its resources in the Polymer library, which serves a few different purposes. First, it is a playground for concepts that were later reflected in Web Components standards. Second, it is a syntactic sugaring on top of the standards to enable a declarative way of creating Web Components through two-way data binding and property observation. Finally, it is a comprehensive collection of over 70 premade "core-" and "paper-" Custom Elements that can be used in UI and client/server communication, either directly or as a basis for more sophisticated elements.

A Dart port of Polymer, Polymer.dart, is used in the Dart ecosystem as the replacement for its Web UI library. This means Web Components are the suggested way to build interfaces of Dart web applications. However, Polymer is not the only library to embrace Web Components.

Google's AngularJS framework is set to switch to Shadow DOM and Custom Elements in its 2.0 release, which is expected to be available by the end of 2015. The recently released Dart port (Angular.dart 1.0) uses Shadow DOM already.  Despite pressure from Polymer, Angular does not redefine itself as a competitor to it. In a message posted in June 2014 to a Polymer mailing list, Angular 2.0 team member Rob Eisenberg wrote, "Angular is really designed around optimizing application development (including DI, routing, templating and decorator directives, more advanced databinding) while Polymer is really optimized around custom element development."

On the other hand, the path taken by Angular 2.0 is widely criticized in the developer community, to the extent that Rob Eisenberg decided to quit the project in November 2014 and focus on his own framework, Durandal, which will also most certainly incorporate Web Components.

Ember, a framework often compared with AngularJS, has also demonstrated it will play well with Web Components. The Ember.Component model is inspired by the Custom Elements spec.

ReactJS, an applauded library for building efficient UIs with the help of a virtual DOM and a one-way data flow created by Facebook, is also preparing for the Web Components revolution. It is already possible to use Custom Elements as part of React views. With an architecture called ReactiveElements, it is now also possible to use React inside of Custom Elements.

Building atop a standard specification, we should see 2015 as the year when previously monolithic application frameworks such as Angular, Ember, or highly specialized frameworks such as React, cooperate together based on Web Components or risk becoming obsolete.

The wonderful world of Custom Elements
The big benefit of Web Components comes from Custom Elements and the ability to distribute them in packages that can be loaded using HTML Imports.

The emerging community is creating hundreds of Custom Elements already, most of which are developed in public on GitHub and made available under permissive open source licenses, such as MIT.

The first stop for finding a community-developer Custom Element is CustomElements.io, a directory created by Zeno Rocha. CustomElements.io uses the Bower package manager registry as the data source and lets you search through more than 600 available components.

Bower is a tool that has gained a major following among developers using Web Components. It offers unprecedented abilities to maintain a list of client-side dependencies and works with any Git or subversion endpoint or even packages distributed as ZIP archives.

Component.kitchen is a directory of more than 500 Custom Elements, curated by Jan Miksovsky. Jan is also building his own component library called Basic Web Components, which already consists of approximately 20 elements that implement the most common UI patterns, such as datepicker or dropdown that are not found in Polymer.

Mozilla has created Brick - a collection of ten Custom Elements intended to be used on mobile platforms such as Firefox OS. Mozilla has been a long-term participant in shaping the Web Components ecosystem. In 2012, it created X-Tags, a Custom Elements polyfill and syntactic sugar library, which now seems to have deprecated since Mozilla decided that Brick 2.0 will build directly upon the Custom Elements spec.

Other noteworthy collections of Custom Elements include Juicy, Akyral and Baasic - all filling in the gaps of missing UI elements for the componentized web.

Also worth mentioning is Vulcanize, a tool developed by the Polymer team, which allows developers to combine several HTML Imports into one. This solves the problem of excessive network traffic that is required to load multiple imports in a single application.

Challenges
While HTML Imports solve the problem of dependency loading, there are still a few issues that Web Components need to solve in the long run.

One of the current pitfalls is that it is hard to load HTML Imports from multiple locations. The dependency tree is solved using the URL of the HTML Import, so if you are using two elements that depend on the Polymer library, you should put them as siblings in the same path.

Similarly, it is impossible to use two versions of a Custom Element throughout the application, since the elements are registered in the same namespace. For most projects that should not be a problem, but it may cause an issue when one of your components insists on upgrading Polymer to its newest version, as this can have an effect on other components. A similar problem exists with the jQuery library, which has created a method to use it in a "no conflict" way. Perhaps we can expect Polymer to work out a similar solution.

Is thick client the way to go for business apps?
One thing that Polymer, Angular and Ember have in common is embracing the thick client pattern in web applications. Thick client strategy is convenient for B2C applications that iterate quickly with cross-platform features, but does not satisfy enterprise users who are unwilling to sacrifice the stability and consistency of their applications.

The modularity of Web Components allows for designing applications that don't necessarily follow the thick client pattern. For instance there is Meteor, a framework for building applications with a JavaScript backend that can either be a thick or thin client depending on the need, and it integrates well with Web Components.

Starcounter uses the benefits of Web Components to collapse the stack between the client and the database in the MVVM architecture. A Custom Element called puppet-js enables two-way data binding between the client and the server using the JSON Patch (RFC 6902) and WebSockets protocol. As a result, developers follow a much simpler, declarative style of programming. Meanwhile, customers enjoy richer and by orders of magnitude faster UI compared to common REST-based applications.

Predictions for 2015
By all accounts, Web Components will continue to impact the client-side library ecosystem. The future will show if it can stand up to its promise of creating standard, interoperable building blocks for web applications. With Polymer set to release a 1.0 version in the second quarter of 2015, it is safe to predict that there will be a lot of developers willing to use it despite the dangers of the infancy period of this technology. When the excitement explodes, be sure to give it a try and share your feedback with fellow developers.