Most Read This Week
Web Components in 2015 By @warpech | @CloudExpo [#Cloud]
Web Components are a collection of emerging web browser standards that can change the way we develop UIs of web applications
Dec. 12, 2014 09:45 AM
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?
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:
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
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.
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 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.
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.
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?
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
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads