At bitHound, two parts of our stack garner the most attention both internally as well as with those we talk to – node.js and Polymer. We recently refactored our 24 custom elements (there's more now) to the production ready Polymer 1.0 platform.
We've been using Polymer's developer preview since the Spring of 2014 so when the Polymer team announced plans to release 1.0 by Q2 of the following year, we took note. This was both exciting and terrifying. The speed improvements promised would be fantastic and we didn't have to blindly ignore performance issues on non-Chrome browsers. On the other hand, we knew breaking API changes were imminent.
Given that we also had our own product to build, questions circled around Do we keep making custom elements with Polymer and pile up the techdebt when we decide to upgrade?, Do we stop building custom elements until we know more? The answer ultimately lay in the middle. We refrained from making overly complex components as we assumed that those might be more challenging to refactor; instead we kept our components as simple as possible. In some cases, things we would normally
componentize we just didn't. As we didn't truly know what would change, we were just guessing.
Expletives filled our Slack channels when we first perused the 0.8 docs. Looking back I had no idea what most of it meant. What the hell is a shady DOM? Sounds like something I can't trust.
I spent about a morning poking around with what it would take to switch our components over. However, our team's workload, the bugs present in 0.8 and the lack of Content Security Policy support made a switch a non-starter for us. We would have to
wait at least for 0.9.
More expletives. We barely had a chance to look at the 0.9 docs when...
We were pretty surprised at the speed at which the Polymer team turned out 1.0, so we didn't quite have a game plan for how or when we'd make the upgrade. But, a week after 1.0 landed, I took a stab at it. Expletives again filled Slack, but reality also set in. We were now sitting on a pile of techdebt. One option was to keep our heads in the sand and keep building on an old and slow platform; but we knew we couldn't keep on compromising the bitHound experience for our users (especially non-Chrome users) and defer an upgrade for too long.
I then spent about half a day poking around with the new platform and testing it on a simple button component. It became evident that upgrading was going to be possible without being a significant drain on our own resources. The race was on to get the upgrade done. We didn't want to wind up in a state where we would have to support two versions of Polymer with the same set of components.
We then noticed we lost features like the
tokenList which we had previously relied on for simple CSS classing and being able to use property values in templates without wrapping them in superfluous tags. But given the speed improvements we took these as necessary sacrifices that would be able to live with.
On the other hand, some new features that made it in 1.0, like Behaviors allowed for the creation of common modules that any component could take advantage of. This significantly sped up the refactoring for some components by sharing common code.
Polymer's Migration guide and the Polymer Slack group wound up being great places to turn to when I got stuck. Check out more resources at the end of the post.
In going through a year's worth of components, we found it more challenging to relearn the nuances of each component than it was to migrate to the new platform. No matter your best intentions when initially writing code, it still remains a challenge to pick up year-old code. It turned out that our components could do on 1.0 what they did before. The implementation changed, sure, but the functionality stayed the same.
In a week, nearly to the hour, a pull request was ready for review. I was able to demo our site running Polymer 1.0 to the team. Reaction to the speed was great. Reaction to the code was mixed as the Polymer way of doing things takes some getting used to, especially since it was different than what we already thought of as the Polymer-way.
Finally some serious techdebt was paid down and we can now look forward to using Polymer to its fullest with less apprehension. We're excited to grow along side this platform and can't wait to see what new features will be introduced (or perhaps re-introduced!).
Here are some resources we found helpful during the transition to Polymer 1.0:
- Polymer Slack Group Search to find answers to questions you might have. There's a good chance someone's asked it before.
- Polymer Project Home
- Vulcanize Concatenate all your components into a single file
- Crisper Make your components CSP friendly
- Hydrolosis Static analysis for Polymer components
- Polymer Starter Kit – Get started quickly with a skeleton project
- Addy Osmani on Twitter
- Eric Bidelman on Twitter
- Rob Dodson on Twitter