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
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.
The opening case study talk from ING was great. Great schedule placement, great delivery, good content.
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.
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.
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.