I'm the engineering lead of Google Santa Tracker (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 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 games and snowball fights.
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 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 📹 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. 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, 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. 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.
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. 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 frameSome 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...
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 🧝♀️, 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.
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 use throughout the year. This is maybe especially true where I live in Sydney, 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.
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.
Thanks to everyone who helped with Santa Tracker this year.
Top comments (8)
Wow, fascinating read. Incredibly honest assessment.
I think it's awesome that the Chrome/Chromium team uses dev.to as a blogging platform! I really appreciate all of your work, and I really like the post. Technical debt is something that's pretty hard to overcome and it's interesting to hear how you tackled it!
You'll find us all around the web—on YouTube, on other blogging platforms, on web.dev, on developers.google.com/web. 👍
Great story. Reminds me a bit of our journey to get the iOS app out the door, albeit at a much different scale, technically and corporately.
Identifying and Mitigating the Ninety-Ninety Rule in Software Development
Ben Halpern
Thanks, I'm glad you liked it. Santa Tracker, the web experience, is the work of many people over ten years.
Now, I know the reason why there are no Santa Tracker Developer day in 2018 in Chrome Devs Youtube channel. I can't wait your team rebuilt santa tracker with lit-html next year. 😍
Yup, I was... busy :)
We do think lit and a new design has tangible benefits too. It should be more performant. But that's a small improvement not worth missing whole parts of the site for!
Great engineering story, Sam.