Google just announced a re-designed AdWords experience. In case you’re not familiar with AdWords: businesses use it to advertise on google.com and partner websites. Advertising makes up majority of Google’s revenue, so when Google decides to completely redo the customer-facing front end to it, it’s a big deal.

The Dart team is proud to say that this new front end is built with Dart and Angular 2. Whenever you asked us whether Google is ‘even using Dart for anything,’ this is what we had in mind but couldn’t say aloud. Until now.

We asked Joshy Joseph, the primary technical lead on the project, some questions. Joshy is focusing on things like infrastructure, application latency and development velocity, so he’s the right person to ask about Dart.

Q: What exactly did we launch on Monday?

It’s a complete redesign of the AdWords customer experience that is rolling out slowly as a test to a small initial set of advertisers. The most noticeable thing is probably the Material Design look and feel. But there are many underlying improvements to the user experience. Read the Inside AdWords post for more information.

Q: How big is the team building this and how big is the project?

Can’t give specific details but the team has dozens of engineers, and the codebase is in the hundreds of thousands of lines of code.

Q: What's the tech stack?

The new AdWords advertiser UI is built as a collection of large single page applications integrated together in the browser. The browser side stack is based on Dart and Angular2 for Dart. We have some infrastructure built on top of these that we share with many other apps at Google.

Q: How is that different from what the stack your team used previously (for the current version of AdWords)?

The present version of AdWords uses a stack based on GWT. The core foundation of the stack is from about eight years ago.

Q: Why even change the tech stack? Didn't it work?

GWT actually worked very well for us. Eight years ago, different browsers worked very differently. We needed to support IE6 for instance, and that was a big challenge because we were building one of the largest single page applications at the time. Chrome hadn’t even launched yet. GWT gave us an abstraction layer across the different browsers. It also gave the language and tools support to scale to very large codebases and teams.

On the other hand, many things have changed over the last several years with respect to browser technology and UI infrastructure. Browsers have become a lot more consistent in implementing standard APIs. Also, new UI development frameworks like Angular have become very popular. There are new emerging standards like web components that we would like to take advantage of. We also have new languages like Dart that are specifically designed to transpile well to Javascript.

So a couple of years ago, when we were starting to think about building a new version of AdWords with much improved UI and performance, we took a fresh look at the tech stack. We wanted to use the opportunity to upgrade to a modern infrastructure that will serve us well for the next 7+ years.

Q: Can you describe the decision process that had led to using Dart?

Since updating the technology stack that is used for the entire AdWords UI is a huge deal, this has been a multi-year process where we first implemented portions of current AdWords using Dart and Angular. Using this stack, we successfully built a very large internal application before deciding to use it for the new AdWords UI.

Q: Why not Closure lib? GWT? TypeScript? Vanilla JS?

Those are all options we considered very carefully since — given the scale of AdWords — we can’t switch tech stacks easily. We wanted to use a stack that will enable building very large mission critical applications such as AdWords with very good user experience, application latency and feature velocity.

We wanted to provide a lot of flexibility to our UX designers to innovate and build a visually appealing and productive UI.

We also wanted to have world class application latency. A lot of people stay logged into AdWords all day working with large amounts of data. So, having a very fast application is critical.

At the same time, AdWords team as whole is constantly innovating and launching several new features every week. We wanted to not only maintain that velocity but make it even better.

Meeting all these very high bars for user experience, latency and feature velocity at the same time in a very large mission critical application is very hard. We thought Dart and Angular together was a good foundation to build the additional infrastructure we wanted to build for achieving all these goals.

Q: Were your assumptions about switching to Dart proved correct? Was something better or worse than you expected?

Being able to scale to large teams and code bases have been true. Also, having Angular available for Dart has been great. We are also doing fairly well on being on track to achieve our UX, latency and feature velocity goals. These are all areas we continue to work hard on making things even better over the coming months.

One thing we found out was that developers preferred even stronger type checking than what Dart was providing. So, we are very excited about the work on Dart Strong Mode. We are also looking forward to cross-browser, fast edit refresh with the upcoming Dart Dev Compiler. The new js interop is also a big improvement. We also realized that we can’t really use mirrors in production apps and have been avoiding doing that.

Q: How did developers on the team react to the decision to use Dart?

The decision was primarily driven by the engineers on the team. We actually had a very formal evaluation at some point after we had some experience with the stack and a small team of senior engineers considered various options across more than 50 key requirements and unanimously recommended Dart.

Q: How long did they take to learn the new language?

It is typically in the order of a couple of weeks. Since Dart looks familiar to many of the popular languages, developers tend to pick it up pretty fast.

Q: Is it hard to get Dart developers?

In general, staffing up the team hasn’t been a problem. Most engineers join AdWords because they love working on a high impact product, working with large data sets and solving complex problems. Having a state of the art tech stack for building large scale business apps helps as well.

There are some engineers though who have a strong preference for a language and make project decisions based on language. So, we have actually seen some engineers joining the team because they love Dart. There are also probably a few engineers who went to other projects because they loved the language that project was using.

Q: What is your favorite feature of Dart?

I really like how Dart is terse. Angular is also terse. So, with the help of these and other infrastructure we built on top of these, our hope is that the new AdWords UI can be implemented with less than 50% of the lines of code as the previous version while having a similar or larger set of features.

Q: What's missing with Dart?

I think the cross-browser story for fast edit refresh is the biggest gap. It is being addressed with the upcoming Dart Dev Compiler though.

Q: Is there a type of project, software or team to which you'd especially recommend Dart?

With Angular2, the application performance and code size are very similar between the JS and Dart versions. So any team considering Angular2 should consider Dart as well.

I think Dart and Angular2/Dart are especially suitable for large scale business web applications. The tooling support and static correctness checking are particularly valuable for those types of applications.

With the ongoing work on Flutter, Dart could become a good option to consider also for teams that need to build native mobile apps across Android and iOS.

Interested in Dart? Awesome. You can learn about the ideas behind Dart, or you can get your feet wet directly.