I have a reputation, apparently

Turns out I’m known (at least in Developer Relations at Google, I am) for disliking anything that looks like a framework, smells like a framework, or sounds like a framework. I don’t like Inversion of Control; I want code to play by my rules, not force me to play by its.

In a framework, unlike in libraries or normal user applications, the overall program's flow of control is not dictated by the caller, but by the framework Software Framework - Wikipedia

I don’t like Inversion of Control; I want code to play by my rules, not force me to play by its.

I’ll be blunt about my feelings on Polymer 0.5, which I considered a framework: it gave me all the wrong feels. It tried to do so much, and in one go, and it felt like eating a 5 course dinner when all you wanted was a salad. After all, there’s no hard requirement to make your own elements. Semantic markup does just fine, and it’s hard to beat the browser at components that its engineers have had years to refine.

There was a scent of “pop this script in the head, and that includes the polyfill as well, oh and while you’re here just hide everything in until all your components have bootstrapped because FOUC.” All of which made me uncomfortable. Lazy-loading, non-blocking, progressively enhancing pages are a core strength of the web. We need to make use of that, not get in the way of it.

It was, in many ways, unfair to judge Polymer so harshly at that stage, because it was labeled as 0.5, not 1.0. Nobody said it was production ready; it was still a work-in-progress!

Ohai Polymer 1.0!

At Google I/O this year we announced that Polymer is now at 1.0, and I knew from 0.8 and 0.9 that Polymer had been to the gym and slimmed right down. It was looking lean, mean, and very promising. I have something of a policy of giving 1.0 releases a decent go (I did the same with Dart), so I decided it was high time to see if I could get a pattern that preserves the best of the web (progressively enhanced and non-blocking) with the future-facing goodies of Web Components and Polymer.

I'm not saying they were "inspired" to make the Polymer logo based on the design of my site. I'm also not saying they were going to call it Paulymer, either.

Lazy-loading, non-blocking, progressively enhancing pages are a core strength of the web. We need to make use of that.

Here’s what I reckon is worth knowing for Polymer 1.0:

It doesn’t include any polyfills. That’s good, because I reckon we only want to get the polyfill if we absolutely need to, not by default. We will need it for any browser that doesn’t support Web Components (so Chrome is the only exemption here), but hopefully more browsers will support Web Components, and the need to polyfill will reduce.

That’s good, because I reckon we only want to get the polyfill if we absolutely need to, not by default. We will need it for any browser that doesn’t support Web Components (so Chrome is the only exemption here), but hopefully more browsers will support Web Components, and the need to polyfill will reduce. It comes in three tiers. There’s micro, mini, and standard. Each builds on the tier beneath it. If you want anything interesting I reckon you’re going to need standard, but if you just want a light wrapper around Web Components then it’s micro for you! In my case I want some of the standard features, so that’s what I grabbed.

There’s micro, mini, and standard. Each builds on the tier beneath it. If you want anything interesting I reckon you’re going to need standard, but if you just want a light wrapper around Web Components then it’s micro for you! In my case I want some of the standard features, so that’s what I grabbed. Elements aren’t included. That’s also good, because if I want to include Material Design elements (or any others for that matter) I would want to opt into that. I’m not going to cover the Paper, Platinum, Neon, or Iron elements in this post. That’d be like reviewing a UI kit, and at this point I’m more about using Polymer as a component author. That said, everything I’m saying in this post should still apply.

The first two are changes from 0.5, the last isn’t, but the changes are important, because they require far less investment from a developer point-of-view, and they put you back in the driving seat. Less like a framework, more like a library. Less like being given that 5 course dinner, and way more like a badass componenty buffet. That could totally be a thing.

Disclaimer: there’s nothing spectacularly “new” here advice-wise, this is just about applying known performance techniques in a Polymer world and seeing if the two can peacefully coexist. (Spoiler: yes, they can.)

The performance problem

The samples and documentation often put the polyfills and HTML imports in the head of the document, both of which are render blocking. They also hide all the elements until they’ve all fully loaded, at which point they get shown. (You can do that with conveniences like the :unresolved pseudo-class, which will will get removed when an element is upgraded).

The net result of both of these is that the user sees nothing until everything has loaded, but with a bit of judicious reworking, we can get things loading and rendering progressively.

Right, here goes…

Step 1: Inline styles and region your app

This one is useful, whether or not you use Polymer. Let’s say this is the layout of your app:

A sample site layout. We normally know the proportions and, you know, we can flexbox.

You probably know the layout of your app ahead of time, so why not just send down placeholder styles in your HTML?

You could wait for all the components to download, then you could assemble them in some kind of JavaScript-based bootstrapping process. Or maybe you’d do it as part of a container <my-app> tag’s scoped styling.

My problem with this is that you probably know the layout of your app ahead of time, so why not just send down placeholder styles in your HTML? Why wait and block rendering? It can be as simple as the major regions of your app, and perhaps some coloring info, like toolbars or buttons.