How can I learn Google Polymer

Web components with polymer

Where do we stand with the implementation of Web Components after version 1.0 has been completed?

The basic idea of ​​the web components is to enable the development of reusable user interface elements based on an open web standard, the so-called custom elements. These elements can be integrated through an HTML import statement and the use of a self-definable HTML tag - all of this natively in the browser without having to use external libraries. Web Components are currently specified by several editor’s drafts of the W3C exclusively by Google employees. Web Components extend the power of HTML for the developer. For example, HTML currently does not offer the option of declaring markup fragments as templates so that they only become visible when a custom element is actually used. The editor’s draft defines the HTML template that enables the declaration of such HTML fragments.

Another important proposal is the introduction of the Shadow DOM. It refers to the ability of the browser to include parts of the DOM (subtree) when rendering the page, but which are not part of the DOM of the main document. This enables extensive encapsulation of the components.

In order to be able to use custom elements, one must be able to import their definition, similar to what is necessary with object-oriented languages. This is done using HTML imports, which are nothing more than links to external HTML documents. If the parser encounters such imports, an import map is created and the HTML documents are loaded in a defined order. The so-called de-duplication is ensured, i.e. already loaded import paths are ignored.

Polymer - from 0.5 to 1.x

A lot has happened since Alex Russel introduced the Web Components [1] idea in 2011. The pure concept work at that time has now become a reality. Google published the Polymer framework back in 2013 and Chrome has natively supported the web component specification since 2014.

So far, however, Chrome is the only browser that fully implements the specification; after all, the web component specification comes primarily from Google itself and little effort has been made to involve other browser manufacturers. So it has not yet been possible to agree on a common specification. In November 2014, Google released version 0.5, the first complete polymer implementation. This already showed the potential of using Web Components, but also revealed deficiencies in the implementation. The constant changing of the specification and too great ambitions in the provision of new functionalities made polymer practically unusable for larger projects.

This was particularly evident in browsers with little native support, such as Internet Explorer (IE). The applications created were slow to the point of being unusable. In fact, speed differences between IE, Firefox, and Chrome are still clearly noticeable today.

Polymer 1.0 - What changes do developers have to deal with?

With Version 1.0 of Polymer, which was completed somewhat hastily for Google I / O in May 2015 [2], Google now wants to have raised the framework to a new level and believes it is ready for production. What has now changed in relation to version 0.5? It was recognized that the complexity of the shadow DOM implementation using polyfills is an obstacle and so the shadow DOM became the so-called Shady DOM - a DOM version specially optimized for performance with the associated access methods.

The (one-way, two-way) property binding can now be adapted more precisely to the requirements of the application logic. The two-way binding is technically complex and not necessary in every case. It should be avoided where possible. The extensive expression syntax has been dropped, probably for performance reasons or due to lack of time to complete. The Computed Properties can serve as a simple replacement, they are more powerful, but of course not quite as expressive. If their power is not sufficient, the earlier expressions can now be implemented using JavaScript. The code quickly fills up with a relatively large number of functions that only serve the computed properties. This has only been improved with the latest version 1.2 through the introduction of so-called compound bindings. This means that bound variables can now also be part of a longer character string.

Last but not least, both tags and properties have been renamed with 1.0 and the option of inheriting from your own elements has been removed. Instead, the behaviors were introduced - a kind of code mix-in. The bottom line is that too far-reaching, too ambitious concepts have been removed and adapted to the reality of what is currently technically feasible. The big changes related to 0.5 seem sensible and the effort invested well, even if Polymer 1.x is an almost completely new framework. If you want to change, this means a lot of effort for everyone who wants to migrate their projects from 0.5 to 1.x.

However, polymer 1.x also leaves the impression of “unfinished”. Perhaps the time pressure was too great due to the presentation at Google I / O. This impression arises, for example, when looking at the polymer element library. Some UI elements were not yet available at the launch or have not yet been implemented without errors. These gaps must be closed accordingly in the project, which means additional work.

However, thanks to Google's active continuation, the framework and the element library receive constant updates and new elements are added. So it is only a matter of time before the level of 0.5 is reached again. For a modernization project in a corporate environment, we had the task of migrating a code base that had already been created on Polymer 0.5 to the current status. The changeover to the new APIs was not just hard work. The fundamentally different behavior and the above-mentioned gaps in the scope of the UI elements also generated the greatest effort. Previously existing elements also had to be re-implemented.

Is Polymer 1.x ready for production?

All in all, Polymer 1.x is a good ones version. The essential ideas of the web component specification can be used simply and efficiently, just like the already finished UI components. Of course, not everything is perfect, but a good basis has been created for further maintenance. Now nothing really stands in the way of productive use.

Use in the enterprise environment

Large companies - many teams - complex projects

The requirements in terms of user experience (UX) are also increasing for business applications in order to enable suitable user interaction in complex contexts. The ubiquitous CRUD masks are no longer sufficient for this. Web Components enable the provision of new metaphors [3] and sophisticated user dialogs in a structured and reusable form, but require a high degree of technical structuring.

In the environment of more modularized applications, which we will hopefully encounter more frequently in the future, the use of components enables the largely uniform implementation of modern UI concepts. The use of Web Components in such projects thus appears attractive. Whether this is sustainable in the long term depends heavily on the stability of the frameworks actually used.

What does polymer offer the developer?

The big plus of polymer in such business applications lies in the support of component-based development. For the first time, a form of the encapsulation of internal structures and inheritance known from the object-oriented world is possible. At least inheritance is already possible for native HTML elements. Together with a dependency management tool like Bower, even complex dependencies can be mapped, managed and automatically resolved quite easily, similar to how the Java ecosystem has been realizing it for quite a while using Maven or similar tools.

Polymer provides an extensive number of easy-to-use UI elements to get you started quickly. As long as you can use material design and its idea, that is also uncomplicated. However, if the requirements for corporate design or corporate identity do not allow use, you will develop your own UI components. For this you can fall back on a rich fund of basic elements (such as iron-ajax, which enables an asynchronous HTTP call) or behaviors. The possibilities to generate your own documentation of the created elements relatively easily and to be able to subject your own elements to unit tests complete the picture. The well-documented design principles associated with Material Design facilitate the development of user-centered applications that are consistent and intuitive to the user when implemented consistently. If you swap this for the often static UI specifications in companies without an adequate UX concept, the developer lacks the necessary framework. We have seen that this can easily result in a function-centered development, without overarching navigation and interaction concepts.

However, polymer also requires training, and the complexity of development should not be underestimated. Polymer still uses a complex construct of runtimes (different browsers), CSS, DOM, JavaScript and polyfills. The more complex such a web application becomes, the more you have to understand the internal processes and learn to deal with existing workarounds. This is especially true when it comes to page speed. Those who do not implement very simple websites will have to optimize here sooner or later.

So is polymer meant for bigger things?

The use of complex front-end frameworks in large business applications must be carefully considered. The more extensive the desired web application and the more complex the UX, the more sensible it is to use polymer. The more the application should be form-based (CRUD - Create, Read, Update, Delete), the less. When using polymer, it is always advisable to invest in a carefully thought-out and formulated front-end architecture and thus provide structure. This is the only way to tame elemental growth and performance problems right from the start.


In the second part of this series we show the specific technical application of polymer in the current version 1.0.

Literature and Links