I’ll say up front that I’m a happiness is a boring stack kind of guy, so when Elon came up with the idea to switch to Google Polymer, I was apprehensive. I learned web design somewhere between the years of 1995 and 2005, a time of radical change for web design to be sure, but the ideas were quite different than the world of AngularJS, Material Design, and Web Components. Still, I agreed that we could take a look into it. Elon maintained that Polymer would solve several existing problems we had with the site.

About Google Polymer

If you haven’t heard of it, Google Polymer is an open-source JavaScript project developed by Google. It includes things like simplified creation of custom elements, two-way data binding (more on that later), computed properties, conditional and repeat templates, and gesture events. The Polymer Element Catalog is a library of already created custom elements, many of which you will absolutely be using in any project. You hopefully already know about the newer tags added in HTML5, such as <article> or <header> but with Polymer, you’ll be writing things like <my-cool-custom-input>, with all the functionality hidden away in that custom element. Nifty.

Making the Switch

Maybe you’re still considering making the switch to Polymer and don’t know where to start. With a new project, it’s a lot easier because the shift in code organization and design can be taken from the beginning. If you’re switching and you want to take full advantage of Polymer, you’re going to want to re-write all your code. Let me say that again, because it’s the terrifying truth, you’re going to want to re-write all your code. (but you don’t have to!)

It’s not that bad but in many ways it is. Polymer offers a lot of benefits and saves on a lot of coding but in order to take advantage of them and really drink the Google Polymer Kool-aid, you’re going to have to change the way you’ve been writing your website. We began by converting as little as possible, creating a single-page version of the site, using Polymer’s <app-route>, among other components. Because we wanted to majorly overhaul and redesign the itinerary, we took this as the first component to create.

Getting a basic Google Polymer project up and running was really fast. Getting it to work with our existing code produced a nightmare of Frankenstein code. Introducing any new framework is a pain but what allowed us to get going fast is that once you include the polyfill and Polymer libraries, you can pretty much dive in and get going right away. If you want to get your feet wet and create just one small component to start, you can. You don’t need to switch over to anything like TypeScript, for example.

Polymer uses two-way binding, which basically allows you to keep everything in sync between your components automatically. If the user renames an Event in one interface, it’s automatically updated in the Itinerary, without even writing a single line of code. The problem is, we already stored and updated our data in MapData.js and doing it in the Polymer way would have forced us to rewrite all code everywhere. Our solution was to create the ttl-data-bridge, which bridged our old data system with the new data system. Not very elegant, right? Yes, it was a big source of headaches, confusion, and bugs.

Google Polymer makes it easy to create custom components for your website

Every component is bound and, therefore, kept up-to-date automatically.

Finishing what we started

Eventually, we decided to take the plunge and rewrite all MapData-related code, which was the bulk of, well, everything on the site. Happily some of that rewriting was actually just deleting, as Polymer simplifies a lot of data handling and updating. You don’t need to write show and hide calls all over your code when you can write <my-component hidden$=”[[_calculatedHideMyComponent(hideOrShowProperty)]]”> instead. Where we were updating different UI elements on data change, now the components update themselves with data binding.

My suggestion would be to start much smaller and only replace smaller components. Build up to it and don’t try to bite off more than you can chew. You won’t be able to reap all the benefits of Polymer right away but if you have deadlines to meet, it’ll be your only choice.

There are some real benefits

I just said there were some benefits of Google Polymer but what are they? After the horror story I just described, you might be questioning if it’s still the right way to go. I’ll leave the final decision up to you but consider the benefits.

  • Data-binding is really cool. As already mentioned, data-binding saves you a lot of work by updating your variables automatically for you without any additional code. Write <span>[[name]]</span> in one component and <input value=”{{name::change}}”> in another and you get a text that updates automatically on user input.
  • It forces you to code better. It’s easy to write spaghetti code. We’ve all done it. You want to prototype something or a deadline is fast approaching and the quickest way is just to write and write and write but not really think about the bigger picture. I’ll fix it later, except there never is a later, so you won’t. Well the whole point of Polymer’s custom elements is that these encapsulated elements work on their own or according to their explicitly stated dependencies. Technically, you aren’t forced to do anything but if you follow the design principles of Polymer, your code is going to be easier to maintain, easier to read, and easier to re-use. This is where Polymer truly shines.
  • Conditional and repeat templates are cool. Using dom-if and dom-repeat, you can output your custom elements (or anything) according to the data you provide. In just a few lines of HTML, you can automatically show all the map markers on the map, according to ever-changing data. If the user adds a new Event in the itinerary, thanks to data-binding, your Google Map component will find out about it automatically. From there, the dom-repeat iterates over that data and adds or removes markers as required. With dom-if, you can conditionally include components according to variables or computed functions you provide. Pretty slick.
Google Polymer introduces dom-repeat, making it easy to control what appears on your site

An example from our Google Maps code, showing dom-repeat

It isn’t all roses

The pitfalls of Polymer might be a show-stopper for you. In retrospect, I don’t know if I would have implemented Polymer given the effort it’s taken to convert our codebase. Now that it’s part of the project and the conversion is behind us, I’m quite pleased.

  • Lack of documentation: Polymer’s own documentation can sometimes leave you wanting but we all know the most truly important documentation resides on Stack Overflow. Well, don’t expect much here. Things are so dire that the Polymer Slack channel explicitly asks users to post their questions on Stack Overflow, so as to build up the knowledge base. It’s an unfortunate drawback of any new technology. If you’re a web developer who is used to every problem already having been solved 10 years ago on Stack Overflow, you’re in for a rough ride with Google Polymer.
  • It’s too new: I mentioned the <app-route> component earlier in the article. As of this writing, the first thing that appears on the page is app-route 0.9.3, followed by app-route is still in beta. We expect it will need some changes. We’re counting on your feedback! Wait – what?! This is Polymer 1.0, right? That’s not what I want to read on the documentation for a component that is at the foundation of my app! There’s a reason why people still  use old versions of PHP or tried and true programming languages like C++. When using Polymer, be prepared for a cutting-edge but bumpy ride.
  • Browser support: Google is promoting their version of Web Components here and not everybody is on board yet with all of it. The end result is that Polymer is slower in Firefox and performs the best in, you guessed it, Google Chrome. When 53% of mobile users abandon a slow site, this is no laughing matter. And it better be okay to abandon older browsers. Before Polymer, we sometimes tested the site in the abandoned Windows version of Safari. Now it doesn’t load at all. Cutting off support for older browsers could be a deal breaker for your business.

Polymer is a work in progress but it's come a long way

The good thing is that the Polymer community will solve all these problems problems in time. Documentation is growing, programmers are writing articles and asking questions, Polymer 2.0 is on the way, and all browser vendors have already or plan soon to implement the necessary technologies. I expect 2017 to look very different and much brighter for Google Polymer.

Lessons learned

Earlier, I praised data binding but there’s a difference between that and two-way binding. Polymer gives you the option of one-way and two-way data binding, the obvious difference being that the latter also sends changes back up the chain. We got so excited about data binding that we used it everywhere, all the time. This turned out to be a mistake, leading to unexplained or unwanted behaviour and triggering of events. Make sure to reserve any sort of data binding only for when you legitimately need it. Only use it when you have considered what the immediate communication of all data changes might do to your component.

As I said, Polymer is a big shift in thinking when it comes to the technical design of your website. There’s a learning curve and we made our share of avoidable mistakes, had we only understood a particular component’s functionality better. Don’t bite off more than you can chew at once and feel free to introduce Polymer into your project slowly. Although you will want to go full Polymerization, as we have taken to calling it, the beauty of Polymer is you can include as little as one simple custom element, if you so choose.

We hope to continue to share our experiences with Polymer with you as we continue development of Travel to Live. Ask more about our experiences in the comments below!