Thinking in Polymer


I have recently been looking at React JS and Angular 2 with a view to adopting one of them for use in a Single Page App that I’m working on.

However Angular 2 and React try to accomplish very different things and for a fairer comparison we should compare React JS with Polymer JS. Or React JS plus Bootstrap with Polymer JS.

But before we get to that, what is Polymer and why would we want to use it?

A friend recommended that I watch Thinking in Polymer by Kevin Schaaf. This is a 35 minute YouTube video on the ideology behind Polymer. It is a good talk and you might want to watch it yourself, but I’ll provide a summary for you here.

Polymer is all about using the DOM as the framework. Not 100% literally, but the DOM has many framework concepts built into it.

The good parts of the DOM are:

  • component model (the element is a component, the video element is a great example of this abstraction)
  • data flow (attributes and properties on an element, and events fired on an element)
  • declarative format (HTML)

The DOM wasn’t extensible until recently. The missing ingredient was custom elements.

The benefit of focusing on the DOM and custom elements are:

  • All developers have fewer concepts to learn
  • Custom elements become interoperable and reusable
  • No lock in to any technology silo

The primary mission of Polymer is to help us build custom elements. The team at Google found some of parts of the programming became tedious and so developed short-hands for speeding up development and reducing boilerplate code.

The Polymer team sees custom elements as far more powerful than just something for building new dropdown boxes and datepickers etc.

Custom elements are seen as the primary tool for building entire applications.

Three main concepts

  1. Think locally: bite-sized pieces that do one job well
  2. Composition
  3. Using the mediator pattern

All communication between child elements and mediated through the host. The host configures it’s children with properties.

Starting at (13:20) we look at how to build a chat app in Polymer.

All of the code for this demo is available on Github.

  1. Create <input-header> element
  2. Use composition: <input> and
    as children

Syntax is:

<input id=”input”>

is: ‘input-header’


We think of the label as being part of it’s API. When the label changes we want to initialize the input value and the label in the toolbar.

We see the raw techniques, and then see how data binding does this in a shorthand way.

Defining the observer is just shorthand for creating a setter on the element for the label property and calling a function.

When a label changes we propagate that change to the local DOM.

Polymer has a declarative event handler syntax. This is just shorthand for addEventListener.

At (18:44) we see quite a lot of code for doing the updates. The Polymer team invented a data-binding shorthand to reduce the amount of code needed. The data-binding doesn’t do magic, it only acts as a shorthand.

Polymer has mustache/handlebars style {{ }} templating syntax.

It also has a double-colon syntax e.g. {{label::input}}

Polymer has a catalog of ready made custom elements that we can use off the shelf.

We replace the raw element with a fancier input from the catalog – the <paper-input>.

See the demonstration of paper-input

As part of this change, we now listen for the value-changed event:


The next step is to add some more paper elements. Click any link below for a demo:

Kevin Schaaf reinterates that everything uses the 3 earlier mentioned concepts, so although Polymer makes it much easier to build complex apps, it is also easy to reason about, and in that sense it takes a lot of complexity out of builds apps.


Building a Polymer app is like this

At 27 minutes, Kevin moves on to the next part of the app, the chat thread view. We are introduced to dom-repeat, a template repeater which creates one instance of the template for each element in our array, and keeping the data in sync.

Also discussed is Polymer’s structured data API. Anywhere in an element you can modify structure data, and the API ensures that any element you share using the data-binding will be notified of those changes.

We have our chat app done by composing three elements together:


With <chat-thread-view> complete, we no longer need to think about those details and can just think of the <chat-thread-view> as a single unit.

One level up from <chat-thread-view> is our <chat-view> custom element, which is composed of our <chat-thread-view> as well as <iron-ajax> and <chat-thread-list>

Kevin finishes by saying you could put this element into a more complex app such as Gmail and it would just work.

And that’s all there is to it. I recommend checking out the code for yourself.

As to how it compares to other JavaScript software such as React JS and Bootstrap, I am going to do some more research and practice with Polymer and then I’ll let you know my views.

Further Reading

Polymer and Progressive Web Apps – Taylor Savage at Google I/O 2016

Kevin Schaaf at Google I/O 2016 – Progressive, Performant, Polymer – Pick Three

2 thoughts on “Thinking in Polymer

  1. Pingback: Polymer and Progressive Web Apps – Google I/O 2016 | Zombie Code Kill

  2. Pingback: Choosing a JavaScript Framework | Zombie Code Kill

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s