This article is an introduction to a series of posts related to Web Components and Polymer. In future posts, we’ll dive into Polymer specifically.

Today, client-side web applications are much more complex than they used to be. Perhaps, even more complex than server-side applications. To help companies build great User Experience (UX) and consistent User Interfaces (UI), we have traditionally relied on style guides and wireframes.

This approach is fine for small projects. Unfortunately, it doesn’t scale. As soon as multiple teams are involved in building the UI, it becomes a nightmare:

  • Different teams have different pace and priorities
    • You need to maintain multiple versions of the wireframes
    • You never know which version has really been implemented
    • You often end up with multiple implementations of the same component
  • Wireframes are static
    • The interaction between components is subject to each team’s interpretation
  • Wireframes are too easy to change
    • Frequent changes to the wireframes increase the technical debt

Today, it seems that the cost of consistency is re-building the same piece of UI after the fact, which is kind of a waste of time.

In this series, we’ll introduce a technology that has been on the developers’ radar for quite some time and that addresses the above inconsistencies and reusability challenges – Web Components. By the end, you’lll be writing code that’s closer to this Google Maps example.

What are Web Components?

The idea of Web Components is that you no longer depend on the browser to provide you with native elements. You can build your own! And that’s very exciting. This idea of components isn’t new, but this new attempt is very promising as it’s already been adopted by some of the major Web-players.

Web Components are a collection of W3C standards that allow us to create reusable HTML elements and to fully encapsulate all of their JavaScript, HTML and CSS. In a nutshell, that means the styles always render as we intend, and the HTML is safe from the external JavaScript.

These W3C standards are:

Template: Think of a template as a content fragment that is being stored for subsequent use in the document.

Custom Element: It lets authors define their own HTML elements that can be used in HTML documents. It can have its own scripted behavior and CSS styling.

Shadow DOM: Provides encapsulation for the JavaScript, CSS, and templating, which are separated from the main document.

HTML Import: Provides a way to include and reuse HTML documents in other HTML documents. It is intended to be the packaging mechanism.

Throughout this series, we’ll explore Web Components by building a sample application using a library called Polymer.

What is Polymer?

Polymer is a library built by Google that sits on top of the Web Components standards. It’s designed to make it easier to extend the vocabulary of HTML, and it is faster for developers to create their reusable custom elements. It also comes with modern features such as two-way binding and property observation to help build sophisticated UI with less code.

Because the library is built on top of Web Components, all the components created will be natively compatible with other Web Components. For instance, components built with other libraries such as Bosonic or X-Tag.

Conclusion

In a world where we have no idea what we’ll build our future products with, being framework agnostic would be very beneficial. That’s the kind of freedom we are striving for with Web Components!

Also, with UX driving user adoption, companies understand, better than ever, the importance of consistency and quality when building a new UI. That has considerably increased the complexity of web applications, as well as the time required to build and polish interfaces. That’s why it is essential we change the way we build and maintain applications.

Finally, it’s worth noting that Google is looking at plugging Web Components into Angular 2.0 using Polymer 1.0.

In the next post, we’ll build our first Web Component. Stay tuned!

Resources: