I've just come back from the third annual Polymer Summit in Copenhagen – here is a review of my time there.
Big announcement: Polymer v3 coming soon!
This will include…
Back when Polymer started out npm was mainly for Node.js and most of the web used Bower. Now that's stabilised and npm is used both by most web and Node.js projects.
However, there was a reason for the old rule of bower on the client, npm on the server and that was that npm creates a tree of dependencies.
Suppose you have two components A and B, and they both depend on a library X (version 1.0). Now suppose that a new version of X (1.1) comes out and A is updated to use it:
Bower's model is better for web applications (where you really don't want to download two versions of the same JS, ever) but critical for web components as customElements.define requires the tag you register a component as to be unique.
Polymer's solution is to use Yarn – an npm client (so Polymer is now stored in npm) that flattens and resolves conflicts like Bower does.
HTML Imports dropped in favour of ES Modules – this is the first real public indication from Google that this feature (which they've been pushing for a few years) is going to be deprecated.
This is quite painful for the Polymer faithful, but is going to be essential taking it forward.
Current Polymer 2 components look like this:
<!-- my-component.html -->
<link rel="import" href="../../bower-components/polymer/polymer-element.html">
<dom-module id="my-component" strip-whitespace>
<template>
<style>
:host { }
</style>
Template Content
</template>
<script>
class MyComponent extends Polymer.Element {
// Implementation JS
}
customElements.define('my-component', MyComponent);
</script>
</dom-module>
This is great for HTML/CSS tools support, but terrible for integration with anything else. In Polymer v3 ES Module imports will be used instead:
// my-component.js
import element from '../../node-modules/polymer/polymer-element.js'
export class MyComponent extends Polymer.Element {
static get template() {
return `
<style>
:host { }
</style>
Template Content`;
}
}
customElements.define('my-component', MyComponent);
On the plus side this makes integration with other frameworks really easy, and means the tools that already work with frameworks like React, Angular and Vue.js will now also work with Polymer.
On the down side this means native HTML/CSS becomes template strings to the tools that edit this content. That will be difficult to many already working with Polymer.
I think this is the right call. We have already been bumping against the limits of Polymer 2 and this change is going to ultimately be really good for us (even if it means porting lots of web components in the short term).
Google are releasing a command line tool to automatically port Polymer 2 HTML imports to v3 ES Modules, which is is grand idea, but in practice will only work 80% of the time (and we're sure to be on the other 20%). Apparently it relies on JSDoc heavily, so get your comments up to date!
ES Modules are not widely supported yet but are available behind flags or in preview versions in all the major browsers so should be soon.
One important note is that JS import needs a relative file path (unlike Node's require), which means it needs a flattened list of specific dependencies like Bower or now Yarn, rather than npm's trees and file discovery.
YouTube, EA, USAToday and Netflix are all using Polymer for both reusability of components and scale.
Most of these sessions were fairly high level: interesting, but light on implementation detail.
Rob Dodson had an excellent session on best practices with web components:
Monica Dinculescu has built an exceptional prototyping tool that uses Polymer components:
The tool Wizzywid is well worth trying out.
Day 1 left a bit of a hole – in Polymer 1 & 2 <template> tags are performant DOM, but with the move to string literals we end up using innerHTML to populate the component DOM and that is both clunky and slow.
I had investigated one way around this: JSX inside Polymer, but they have something else in mind…
lit-htmlThis uses tagged literals. Basically this turns an interpolated string into a function call:
let template = html`<div att="${foo}">${bar}</div>`;
// becomes
let template = html(['<div att="', '">', '</div>'], foo, bar);
This html function is the core of lit and returns a TemplateResult that works in a similar way to VDOM.
It's not quite the same as VDOM in React (or similar) – instead of updating the entire virtual tree and then finding only changes in the DOM it updates only the DOM it found to be dynamic.
There is huge potential to this approach, but it's very early days. The big advantage over JSX is no tooling support required. html is a run time parse, but it only runs once per template and performance testing and optimisation is underway.
I will go into this in a lot more detail in future blogs.
Ionic outlined another approach that doesn't use Polymer at all (but does use web components).
Stencil uses JSX and TypeScript, but instead of compiling to call a framework like React it compiles to the native JS. It also uses the same asynchronous DOM changes as React Fibre to make VDOM changes to lots of elements at once fast.
This means Stencil's components are small, fast, and have no dependencies at all. They'll play nice with anything. It does also mean that they have more repeated code, but you'd need a lot of components (each with a small overhead of repeated JS) before that became more than even a lightweight framework.
This is kind of the opposite direction from lit. Comparing both to React's mix of JSX tools and the framework to support their output: lit does away with tools completely, while Stencil is a build tool that does away with the framework.
Afternoon sessions focussed on SSR for bots – a weakness for any PWA/SPA (but especially one that uses web components) because of JS client rendering (which bots might not run) and shadow DOM (which bots can's see).
Rendertron is a Docker image with a headless Chrome implementation that can load a route, execute all the JS and return a static version of the HTML.
Martin Splitt's talk on VR/AR was fascinating and entertaining:
Sam Thorogood presented a good primer on ES6 modules:
And, of course, Surma and Monica Dinculescu (and a little recorded Paul Lewis) presented Supercharged LIVE LIVE LIVE:
Polymer has a bit of a reputation for always announcing the next new big thing. To some extent this summit was no different, with Polymer 3 making some quite drastic shifts of the goalposts. However, this time I think this shift is towards (rather than away from) where the other frameworks are going. It's a shift they need to make.
I'm excited about what we'll be able to do with Polymer 3.
I learned a great deal and met a lot of fascinating and talented people.
I also want to say that the entire summit was exceptionally well run, and the "be excellent to each other" code of conduct is something every event should have. This was the most diverse developer event I've ever attended, and also one of the best.
lit-html is exciting, but it's early days.
