Hello Polymer: Q&A with Google’s Polymer team

Today, there was an online event called “Hello Polymer”, in which Polymer team members Eric Bidelman, Alex Komoroske and Matthew McNulty talked about the framework. This blog post summarizes what happened.

The actual video of the event starts at 2:40.

Goals and nature of the project

Web components are a set of APIs (shadow DOM, templates, custom elements, etc.) that will enable cross-framework widgets and user interface elements for the web. The main goal of the Polymer project [1] is to help with designing those APIs. To that end, it polyfills them on modern browsers so that experience with them can be gained – with real projects. The Polymer team closely collaborates with web standards bodies, contributors to various frameworks and the Blink team.

The following diagram describes the architecture of Polymer:

• platform.js: The red parts are shims [2] for upcoming APIs. These shims will be used by most frameworks in the future and eventually be replaced by native APIs.
• polymer.js: The yellow parts express a taste in frameworks – how the foundational APIs should be combined. It is but one of many ways of doing so.
• The green parts are Polymer elements, web components built on top of polymer.js. Not all elements display something on screen. For example, the element polymer-ajax. The Polymer documentation lists all elements that are currently available. The plan for Polymer UI elements is to make Google’s design skills (as, e.g., demonstrated by the Maps app on Android and iOS) readily available on the web.

Polymer’s philosophy

This is how the team describe’s the project’s philosophy:

• Embrace HTML. Everything is a custom element (even non-visual components).
• Leverage the evolving web platform: get smaller and better over time.
• Minimize boilerplate code:
  • Remove the tediousness of building web apps (natively).
  • Provide a feedback to to web platform standards.
• “Salt to taste”: Polymer is designed to be à la carte. Every framework can pick and choose what it needs. Web components will provide a thriving ecosystem for everyone. That’s why the Polymer stack is layered.

Demo

A quick demo starts at 15:07 (and lasts until 21:44):

• Create a custom element in a text editor.
• Look at the element in the (still very basic) GUI editor “Pica”.
• Use data binding (yt-search-video is a YouTube component):

      <yt-search-video imfeelinglucky="{{$.input.value}}" ...>
  

Questions and answers

The Q&A starts at 21:45.

• How does Polymer fit into the current framework landscape?

  It’s main goal is to bootstrap an ecosystem around web components. Everyone will profit from the powerful widgets created as part of the project. Framework authors can use what they want from Polymer and ignore the rest.

  Additionally, the Polymer team wants to figure out how to best use the new APIs and to help people with them. Polymer is work in progress. While there are people on the team that have much experience with various frameworks, the setting of Polymer is completely new. All of a sudden the DOM is the framework. As a consequence, if something doesn’t work like it should, the team gives feedback to standards bodies and tries to fix it. The mission of Polymer could be described as “help build the web of tomorrow”.

• Is Polymer already being used at Google?

  Polymer is still pre-alpha! But there is much interest from within Google and from framework authors.

• What browsers are supported by the polyfill?

  Polymer works on the latest versions of all browsers (Chrome, Firefox, Internet Explorer, etc.). Older browsers are ignored. Polyfilling on them is simply too difficult and Polymer needs to look ahead in order to make progress. Some things can’t be polyfilled perfectly on all browsers yet (e.g. the encapsulation provided by the Shadow DOM), which means that Polymer has to compromise and/or wait for browsers to catch up.

• Can you build raw web components that don’t depend on something Polymer-specific?

  Yes you can. Polymer [as opposed to platform.js] is a very thin layer that will get even thinner over time.

• Why must custom element names have a dash?

  You don’t want to break existing content if you add new tags to HTML. Thus, the names of the latter tags will never have dashes in them. The original rules for the names of custom elements were more complicated (a prefix x- was required), but the Polymer team figured out a simpler way and gave feedback to standards bodies.

• What does the <g-app> tag in the Google I/O Polymer video mean?

  It has nothing to do with AngularJS (and ng-app), it’s simply an example of a custom tag.

• How does Polymer work with AngularJS?

  AngularJS taught people how to think declaratively. Web components are framework-independent. The only thing that is tricky is to combine Polymer with another framework inside a web component.

  [Additionally, AngularJS and Ember.js have announced their migration strategies towards web components [3].]

• Are there build tools for packaging (concatenating, minifying, etc.) web components?

  It’s still too early, but first experiments have started.

References

1. Google’s Polymer and the future of web UI frameworks
2. What is the difference between a shim and a polyfill?
3. Plans for supporting Web Components in AngularJS and Ember.js