Skip to content

What I learned at Polymer Summit

This week, I spent 2 days at the Polymer Summit in London. I confess – I went mostly because I planned to be working remotely in London at the time, and this event was (!!) completely gratis (free, $0, £0, etc). At worst, I thought, I could eat for free and mooch some wifi. As someone (probably) said, the key to happiness is low expectations.

So when the event had lots of great content (packed schedule, but with a nice healthy amount of breaks) and I have a few things to write about so I don’t forget them, I was very pleased.

Acronyms and #hashtags

Two acronyms came up a lot, and pretty much because they’d been mentioned at the I/O conference earlier this year.

PRPL (pronounced “purple” as in “the purple pattern”)

  • Push components critical for initial route
  • Render the initial route ASAP
  • Pre-cache components for remaining routes
  • Lazy-load and create next routes on-demand

(from Polymer at I/O post)

In Polymer’s tools, this is the pattern it follows for serving your app. However, you’ll notice that that’s, well, a solid plan for serving most any JS app.

RAIL (Response Animation Idle Load)

RAIL is a “performance model”, or really, a set of goals for performance. It was the first I’d heard of it, but here’s an article from 2015 making me feel out of the loop. The acronyms bits break down into the following goals:

  • Respond in less than 100ms
  • Animate frames every 16ms
  • Idle “maximize idle time” – break work into 50ms chunks
  • Load content in <1000ms (one second)

Those are performance goals that lots (possibly most) web experiences fail.

These acronyms are useful (despite the heavy fate of being an acronym), because they don’t really have much to do with Polymer, but a lot to do with doing development on the web. Perhaps unsurprisingly, Google has nice articles on both RAIL and PRPL.


This was the hashtag that almost every talk had in it – I had mixed feelings on this one.

On one hand, this motto is great! Leverage the power of the browser, act like you’re in a browser, use the current and emerging APIs afforded to you.

On the other hand, this motto felt a little icky, grouping web developers into the herds of “platform developers,” in my mind. As much as I love my mobile development friends, I don’t envy that they wait with anticipation and a drop of dread for announcements from their platform-owners (Apple, Android, Windows). I would like to imagine (pretend?) that web developers don’t have the same fate, that conversations about the platform are done in the open, yet … this is something I have to think about.

Favorite talks/Recommendations


The opening case study talk from ING was great. Great schedule placement, great delivery, good content.

Something I really liked (paraphrased): “JS devs won’t like Polymer, because it’s web-based not JS based.” This was an interesting jab at JS frameworks, using JS, bundlers, and all that jazz to make applications, rather than (wait for it) #Use[ing]thePlatform, using HTML/CSS/JS and not the (somewhat popular currently) strategy of “what if everything [including CSS] is JavaScript”

This one was a great overview of what you get from Firebase, which is something I’m interested/will probably lead a workshop on in the near future.

Most fun/entertaining

Monica’s talk on Progressive Web Apps was really great, and a good end-to-end of building an app.

If you’re interested in Polymer or web components, but haven’t used it enough to be interested in all the “and now you have XYZ!” announcements (*cough ME cough*), the livecoding session was quite enjoyable.

Most interesting

The most interesting + intriguing, and possibly my favorite talk, was about mobile+web performance. The title doesn’t communicate as much as I would hope (description is more helpful), but expect to learn a bit about how just plain physics are a big chunk of why websites are slow on your phone.

Shoutouts for friends

Blatant shoutout, but I think they did a great job. Lorenzo and Riviello spoke about how Comcast (Philly represent, also they gave LibertyJS a shoutout so they earned my loyalty easily) has used Polymer since v0.3. In case you were curious, YES, it IS extremely difficult to promote and adopt an emerging technology at Comcast, much less a technology that was still in alpha when they adopted it.

Also, the static image for this video should totally be the cover for Lorenzo and Riviello’s boy band. Just putting that out there.

Thanks, Polymer Summit, for a great event! You’ve made me VERY tempted to use web components so as to justify a trip to next year’s summit 😉 Oh and lest I forget, the codelabs were also great! At the summit, the one I tried to go to moved too quickly for me to follow, but they’re well-documented online and I love that they have a “remaining time” counter.

4 Replies to “What I learned at Polymer Summit”

  1. Did you just hear me LOL all the way from Philly to London? Now Chris & I just need a name for our boy band to go with our photo 😛

    Definitely agree with you about the other talks you highlighted, they all had some really great actionable and/or entertaining content. The Physical Web talk also got the wheels in my head spinning around pretty fast.

    Great to see you there! Enjoy the rest of your time in London.

    1. Nice! I was on a call during Physical Web unfortunately :/ The JS meetup has some beacons if you’re ever curious!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.