The Gift of Giving Up
Tags: santa, google, javascript
Published: 2018-12-25 02:43:42

---
title: The Gift of Giving Up
published: true
description: Santa Tracker and the art of code migrations
tags: santa, google, javascript
cover_image: https://thepracticaldev.s3.amazonaws.com/i/rlx6a9gs80ahnumi11ez.png
---

I'm the engineering lead of [Google Santa Tracker](https://santatracker.google.com) (on the web), a holiday-themed experience for everyone. The team is made up of 20%-ers (a concept within Google describing "internal volunteering"), although there's a few core engineers who work on the site for a few months before December 25th.

![Working hard](https://thepracticaldev.s3.amazonaws.com/i/s2lekluaspnwvpn1c9de.gif)

Working on Santa Tracker is an absolute joy. We've got pretty hard deadlines—the elves provide us with Santa's flight plan, which always starts at 10:00 UTC on the 24th. But we also launch Santa's Village at the start of December, which is full of educational and fun experiences like Blockly-based [coding](https://santatracker.google.com/codeboogie.html) [games](https://santatracker.google.com/codelab.html) and [snowball fights](https://santatracker.google.com/snowball.html).

Santa in 2018, is fundamentally a Polymer 2.0-based site which includes code that is up to a decade old. It uses the [App Shell](https://developers.google.com/web/fundamentals/architecture/app-shell) model to an extreme—we have about ~50 unique scenes and games that users can navigate to. Some scenes open on different days throughout December, such as the Tracker itself, which only opens while Santa is in-flight.

In terms of tech stack, Polymer lets us build the site 'chrome'—menus, sidebars, buttons and the navigation experience (I made [a video 📹](https://www.youtube.com/watch?v=uaUPNkmVaKs&list=PL5vCN4IjFTd40C6QRiHfs6h4MOdjbRo3B&t=0s&index=10) about this last year). It uses Web Components, which means we also import Shadow DOM and Custom Element polyfills for older browsers. And among evergreens, that just means Edge, and [that likely won't be a problem in 2019](https://blogs.windows.com/windowsexperience/2018/12/06/microsoft-edge-making-the-web-better-through-more-open-source-collaboration/). This isn't an evangelism post, but WCs help us rapidly build out connected components in a standards-based way.

# The Rewrite

So, Polymer 2.0 uses HTML Imports to bring in its dependencies—this is something Chrome pushed for but which never gained widestream adoption. It's being [removed by Chrome around March 2019](https://bugs.chromium.org/p/chromium/issues/detail?id=766694), something which the JavaScript console will happily inform you of. 

Importantly, we suspect Santa Tracker will just _stop working_ for Chrome users in March. ⚠️😱

The solution is to [use ES Modules](https://www.youtube.com/watch?v=fIP4pjAqCtQ&t=0s&list=PL5vCN4IjFTd40C6QRiHfs6h4MOdjbRo3B&index=14). Polymer itself is largely unaffected, but we need to migrate to its 3.0 release, which is a mechanical conversion of 2.0 to use ES Modules instead.

We start development on Santa Tracker around October every year, working for two months until December, and then releasing smaller updates throughout December (sometimes bugfixes, sometimes new games or videos).

This year, we started by kicking off the ES Module migration, and approached this by modernizing Santa Tracker: aka, rewriting the whole thing. This is something all engineers love to do, but we felt that the Polymer-based version, originally conceived around 2013, was showing its age: builds take 20+ minutes, and it uses tools that have been well superseded. It made sense to start a new code base.

![Engineers at work](https://thepracticaldev.s3.amazonaws.com/i/nix2esyu3lk64wwsf3y6.gif)

This proceeded for a few weeks. The "App Shell" I mentioned above was mostly ported. Instead of Polymer 3.0, we chose to use [lit-element](https://github.com/Polymer/lit-element). But migrating each of our 50 individual scenes, the sometimes decade-old code, was proceeding fairly slowly. Challenges like:

* We moved each scene to its own `<iframe>` (for performance and security), rather than bringing the code into the parent frame

* Some modern scenes are specifically written using Polymer 2.0, rather than portable JavaScript

* Tight coupling to the previous build system

This was stressful. It was slower than we needed it to be—because we had literally 50 units of work, it was fairly trivial to see how the project was tracking vs. December 1st. It was going to be necessary to ship a reduced version of Santa Tracker to our users.

And so, after a few weeks being overwhelmed with a rewrite...

![Overloaded](https://thepracticaldev.s3.amazonaws.com/i/5tom7d8gtwq7ddmjkg06.gif)

**We stopped.**

A little over a week before Dec 1st, we just decided it wasn't worth it. We were focusing on _developer experience_—the new codebase was 🌈 amazing 🌈: it compiled our code in 1/10th of the time, it used ES Modules properly, etc.—but shipping it would be to the detriment of our users, who would just see it as missing games or features.

# The Saving Grace

Savvy users might have noticed that we salvaged some of the new codebase. One new game this year, [Elf Maker 🧝‍♀️](https://santatracker.google.com/elfmaker.html), loads the _new_ codebase via the old codebase—you can see this by its `<iframe>` use, and how the game internally uses lit-element.

Despite feeling a bit fragile—to build and release Santa Tracker, we now have two totally separate repositories being combined via an artful concoction of `gulp`, hand-written build scripts, and bash—this *did* work better than anyone expected.

While the team had this idea that a complete rewrite made the most sense, we started with a bit of engineering hubris: of course it's the right decision, the codebase is so out of date, etc. By "giving up" on the complete rewrite, yet still shipping _something_ new, we've learned a lot _without_ negatively effecting user experience along the way.

The migration to ES Modules has to happen by March 2019. But now, we have more data and can make informed decisions to get there.

# Yes, But We Still Have To Do It

We've postponed a problem. The Santa Tracker site needs to be ported by March 2019, but we're now in a much better position to do so.

![Santa practicing](https://thepracticaldev.s3.amazonaws.com/i/b6tyq00ig5itt116yqti.gif)

While Santa Tracker is a holiday attraction, and most of our users visit us throughout December, we are accessible year-round. This is especially true for our educational games, which we know [educators](https://santatracker.google.com/educators.html) use throughout the year. This is maybe especially true where I live in [Sydney](https://goo.gl/maps/VQgUXWHEkBy), where the cold theme makes sense during a whole different part of the year and it is ☀️ 30ºC+ on December 25th.

What this means is that we would like to get the work done before the normal Santa Tracker development cycle in October. But by making the hard decision not to ship the new codebase *now*, to not work ourselves to the bone porting scenes just to get back to _where we started_ (at least from our users' point of view), we can do it properly and without the enormous amount of stress required.

I acknowledge that I am in a position of privilege: most engineers don't get to work on holiday-themed websites, and are instead beholden to their clients, or commercial demands and timelines. But in many ways, Santa Tracker has similar hallmarks—Google does it every year because it's fun and because folks like it, but we have those same hard deadlines—Santa, and the holiday season, is effectively our client.

# The Gift Of Giving Up

The Santa Tracker team is now going to take a well-deserved rest: just like Santa and his team.

![Taking it easy](https://thepracticaldev.s3.amazonaws.com/i/0b58qktiayronxp1bpms.gif)

Yes, we'll have to get back to work early in 2019 to get ready for holidays that are almost an entire year away. But we can do it properly, and without having had to compromise our user experience. To me, this is the right kind of technical debt.

I hope you can give yourself The Gift of Giving Up these holidays, to reduce your stress, while keeping your users just as happy.

<center>🎅🤶🎄🎁</center>

Thanks to everyone who helped with Santa Tracker this year.