Polymer 0.8 Sneak Peek

_{This article originally appeared on the Divshot blog. Divshot is a developer-focused platform for deploying modern front-end applications. It was also started with Intridea’s support by Michael Bleigh!}

The next release of Polymer, 0.8, is going to be a doozy. It’s the first release on the “heading towards production” track and it’s going to have some pretty massive differences from previous versions. So what exactly is new, and what’s changing?

Note: This data was gathered primarily from reading the Polymer 0.8 Primer which is very, very extensive. I’m just hitting the highlights. Also note that any of this could change before the final release is cut.

A Tale of Three Polymers

One of the biggest changes in 0.8 is that there is no longer a single Polymer library. Instead, it’s been broken into the three “layers” of polymer-micro, polymer-mini, and polymer. Why the change?

Remember, Polymer is really just a layer on top of the Web Components standards. Web Components are meant to be inter-operable with each other regardless of things like which framework was used to build them. Creating lighter-weight versions of Polymer makes it an easier choice for authors of reusable components by being less of an install burden. So which library should you use when?

• polymer-micro has only a bare layer of sugar on top of the raw DOM APIs and a few niceties. You don’t get any DOM template stamping facilities, so this is really meant for reusable elements with little to no DOM interaction (e.g. core-ajax).
• polymer-mini layers some DOM control on top of micro and lets you do template stamping (but not template binding). Also gives you access to <content> and the new lightDOM and localDOM properties.
• polymer is the closest thing to 0.5 (but still quite a bit different). It adds on attribute and property observation, template data binding, layout attributes, and more. This is what you’re going to want to use if you’re building a Polymer application.

Things You Can’t Do Anymore

When you first look at 0.8 you may be a bit surprised. There’s actually many things from 0.5 that are gone, vanished, kaput. It all has to do with production readiness. Polymer 0.8 is built to be lean, mean, and a foundation for shipping production code. Some of the more expensive (computationally and/or filesize-wise) features have been nixed. Watch the Polymer State of the Union talk for more detail there.

• Elements can’t inherit from custom elements anymore, only native. It’s marked as a todo, but it’s unclear if it’s a before-0.8-launches todo.
• Template binding is substantially less powerful than it was in Polymer 0.5, as is property observation. Everything’s more explicit, and more is expected to happen in JS vs declared in templates.
• Polymer will no longer ship with a spec-complete Shadow DOM polyfill. This was one of the biggest performance bottlenecks in non-Chrome browsers. The new polyfill implementation will be “Shady DOM” (details TBD).
• Property observation does a bit less magic, you’ll have to manually debounce some things.

Things That Are Different

In addition to removing some of the heavier features, there are also lots of structural changes to how you build custom elements. Here’s a non-comprehensive list:

• <polymer-element> is gone. Now you use the Polymer JS function to register your element, and the new dom-module element to specify templates.
• You use the is property to declare the element name in a Polymer registration, e.g. Polymer({is: 'my-element'}).
• Attribute bindings now work based on dash-case instead of camel-case (i.e. <my-element first-name="{{name}}"> binds to the firstName property. I am super happy about this, camel-case attributes are hideous.
• You should now use the lightDOM and localDOM APIs to manipulate element DOM so that they are maintained properly.

Here, Bite Down on This

I’m not going to lie, if you’re building stuff with Polymer the transition to 0.8 is going to hurt, bad. There’s very little that won’t need to be rewritten significantly (if not from scratch). That being said, this is a totally necessary transition.

As Matt McNulty said in his Polymer State of the Union, Polymer started as an experiment, and with 0.8 that experiment is over. It’s time for Polymer to transition from a fun future-facing toy that we can dream about into a serious, performance-oriented tool we can use to ship real code.

By focusing on performance and footprint, the Polymer team is laying a practical foundation upon which much can be built. And yes, the changes are pretty drastic, but they’re throwing them at us all at once. The plan is for the API to change minimally between 0.8 and 1.0, so (fingers crossed) this will be the biggest rewrite you ever have to do for Polymer.

Lingering Questions

I’ve been drinking the Web Components Kool-Aid since Polymer was first announced at Google I/O in 2013. The encapsulation and composability of custom elements is revolutionary for web apps. As we start looking at the road to production-ready Web Components, however, I still have a few questions:

1. How will module loading shake out? With Mozilla backing away from HTML Imports and ES6 gaining popularity, it seems like there’s a growing rift in how to do this properly. This is a key issue that needs to be sorted out; you shouldn’t need a build step to do basic module loading for a web app.
2. The DOM is big and unwieldy. Can we incorporate some of the gains of Virtual DOM tech into Polymer and/or the Web Components specs themselves? The concept of “Local DOM” or “Shadow DOM” gives us a clean encapsulation point, maybe soon we can get some of the benefits of React and its kin.
3. When are Apple and Microsoft going to get fully on board with Web Components? The true promise of Polymer can’t be realized until we have native browser support for the standards in all browsers.

Questions aside, I’m excited for Polymer 0.8 and we will continue to champion Web Components here at Divshot. Latest estimates put 0.8 landing sometime in March; I can’t wait!