Dev: Developing Gmail’s new look

Nice detail about the flexibility of developing on the web. 

Developing Gmail’s new look

Posted by Mark Striebeck, Engineering Director

Editor's note: This post is more technical than most posts here, but we thought some of you might find it interesting to look inside how development on the Gmail team works.

Developing the new look for Gmail was like the proverbial “changing tires on a moving car” - only that the car is carrying hundreds of millions of users and is under constant construction and development. The two main technologies that we use for these types of projects in Gmail are “conditional features” and “Javascript mods” (other Google products use very similar systems). Both technologies were particularly important for testing the new look.

Let’s start with the first one: conditional features. This is our ability to make changes to the Gmail code that get deployed, but not executed. You can think of it as a lot of if-statements around the new code that get enabled when the conditional feature is on. The conditional feature flag itself is set outside of the deployed code. These flags can be set in various ways: as a percentage of overall users (if we want to rollout a feature slowly), for Googlers only (if we want to use a new feature internally), for individuals (if we want to give users early access to a features) and in many other ways. In short, conditional features allow us to update our production systems separately from releasing new features. This way, Gmail developers can make changes, but don’t have to worry about their unfinished changes being released before they are ready.

The other technology is “Javascript mods”. We use this technology to create modifications for a new feature in Javascript across many files. The main challenge with Javascript is that we want to keep the amount of Javascript code that the browser has to download as small as possible - the more code the browser has to download, the longer it takes to load Gmail. So, we don’t want to include the code from all possible mods, but only the code that’s relevant to your browser. Let’s use our Gmail mobile app as an example: it comes in various forms, including the smartphone user interface (UI), the tablet UI, and the offline UI. All these UIs are slightly different. We don’t want to download the Javascript code for all different UIs to the browser. Instead, our server inspects which browser or device you are using and creates the exact Javascript that you need. The selection of mods can be triggered by browsers, devices and even “conditional features”.

Using these technologies, we can make sweeping changes in Gmail without those changes going “live” before they are ready. Plus, since we can turn pieces of code on or off, we can enable new features in specific environments, such as Google, or for specific users, like the Gmail team, without changing the code itself.