Frank Sommers What is the Google Web Toolkit?

Bret Taylor: The Google Web Toolkit, or GWT, at core is a Java-to-JavaScript compiler. It lets you develop your Ajax application entirely in Java, debug it entirely in Java, and then you can compile that Java application into browser-compatible JavaScript and HTML that runs in any Web browser.

The model of development feels something like SWT or Swing, where you're developing against [GUI toolkit] objects versus developing against Web objects, such as text boxes and divs and forms. We do a fairly sophisticated static analysis of your Java program, and output the optimal JavaScript that will work in any Web browser and platform that's in common use, from Opera, Safari, Firefox, Internet Explorer.

The power of GWT lies in its debugging and development capabilities. The main problem with the concept of compiling Java to JavaScript relates to debugging: when you program something in Java and then compile that into JavaScript, what happens if there is a bug in your program? How do you debug it? That's like trying to debug your C program by looking at the assembly language. That's pretty difficult.

GTW ships with what we call a hosted Web browser. It's a special Web browser we built with hooks back into the Java virtual machine that allows you to debug your entire Web application using Java development tools. You write your Web application in Java classes, and when you start our hosted Web browser. Let's say there is a button in your Web application that normally invokes a JavaScript event handler. When you click that button in our hosted Web browser, it will invoke your Java event handler within the Java virtual machine. You can set in Eclipse a breakpoint in your Java function, start up our hosted Web browser, and when you hit that breakpoint, it will bring up Eclipse with the entire stack trace, all of the debugging information that you used to in Java. Once you're done developing your application, you click compile, and it will compile everything to JavaScript and HTML that can be served from any Web server.

The nice thing about GWT is that it's very genuinely Ajax. You can develop and debug your application in Java, which a lot of developers find extremely valuable, but the end-user only sees JavaScript and HTML. Everything happens in the Web browser. A lot of technologies [such as JSF] do a lot of translation on the server, but still require the client and server incur tons of traffic on the network.

Frank Sommers: Can you walk us through the steps of developing an application with GWT?

Bret Taylor: The development cycle is that you develop and debug in Java, and you deploy in JavaScript. To take the metaphor about C and assembly language I mentioned earlier, JavaScript is our assembly language. It's our output format. You can think of GWT as a cross-compiler. We compile to Safari JavaScript, to IE JavaScript, to Opera JavaScript, and on.

It's amusing to think of JavaScript as an assembly language, but in practice there are so many idiosyncrasies with all the modern browsers, that it's a valuable tool to have a cross-compiler. Just to give you an example, when we launched Google Maps in February 2005, it only worked in Firefox and Internet Explorer, and not in Opera and Safari. The reason was that the sophisticated UI programming we were doing in JavaScript was very different in Safari and Opera. So significantly different that it took us about a month or two to add Safari and Opera support. With GWT, you could write this once, and with no special cases in your code get it to work in all browsers. It's probably not all that big of a difference for small applications, but once your application grows in size and complexity, it's a significant time-saver.

Frank Sommers: How does the compiler work?

Bret Taylor: For Google applications, we're very focused on speed and user experience. The main thing we try to do is reduce the size of the output JavaScript. That is one way we try to achieve maximum performance. Sometimes running a Web application is great, because there is no download, no install required, it just works automatically. But if your JavaScript is 300KB, there is no install required, but your users really are installing it every time they use it, [because] they download 300 kilobytes of JavaScript.

The GWT will do static analysis of the code, and remove all methods that you don't actually call. We do very aggressive static analysis so that if you import a huge Java library, and only use one class, and one method within that class, we eliminate all the other code, and won't output [that] to the JavaScript.

We take advantage of strong types in Java to do this. With a more dynamic language, it would be quite difficult, if not impossible. Obviously, there are more dynamic features in Java, but for the vast majority of GWT applications, the reason the applications can come out compact and so efficient is because we take advantage of very aggressive static analysis.

If you look at popular JavaScript libraries, like the Dojo toolkit, even though they release a few different versions depending on the functionality you want, the most compact version is about a 160KB or so. The kitchen sink, as they call it, that includes all the features of Dojo, is about 200KB. Just to use one feature of that, you have to include all 200KB. All the functionality included in our "kitchen sink" demo is definitely under 200KB, probably around a 130KB. If you use just one feature of our window library, the compiler only outputs that one feature.

That principle is really important, because one of the main problems with JavaScript is code re-usability. If you want to share a large library, it becomes hard in JavaScript because you don't want to force users to download that large library every time. With GWT, you can use a large a large library, and we only output the parts that you use, which is really valuable, particularly for large software development teams.

Frank Sommers: What Java classes can be used in a GWT application?

Bret Taylor: Out of the box, we support almost all of java.lang, except for the threading and synchronization primitives, and we support a fairly large subset of java.util, including the most popular collection classes. We definitely don't support the I/O library. A lot of Java classes use I/O, or are I/O-related, and those we don't support. The vast majority of the core [Java] classes we support. A lot of people have converted existing Java libraries that work right out of the box, they can just compile that into JavaScript.

We released a windowing toolkit that's analogous to SWT or Swing, and is optimized for the Web. You write your user interface against that class library. But you don't have to [use that]. People have written their own custom class libraries on top of that, but we have a really good base level of Web UI widgets you can program against.

Then we have a number of classes that allow for remote procedure calls, or communication with a server. We have a servlet class you can subclass that becomes an RPC endpoint on the server. You can make calls to that from the client, and it will do all the serialization and de-serialization for you. You essentially just pass objects back and forth.

It's a very natural thing, you don't need to think about whether you need to use XML, JSON—it just happens for you. We handle full class hierarchies and polymorphism. If you have a library of shapes, you can pass squares and circles over the wire, and GWT decodes it for you. That's actually difficult to do with JavaScript and JSON, because they don't have the notion of hierarchical data types. It's fairly complex the way we implemented it, but for GWT users, they can just pass objects and send them across the wire, and it just works.

Frank Sommers: How about support for REST or SOAP?

Bret Taylor: We have a demo application that shows how you can take a REST interface and use JSON as your wire format for remote procedure calls. There also other community examples where people have used [GWT] for SOAP.

In the world of Web browsers, you don't necessarily want to use the same wire format you would use for traditional Web services. It turns out that XML implementations in different browser vary a lot in their XML performance. If you use a lot of Ajax and JavaScript applications, unless you have a very homogeneous deployment environment—like one company that uses the same browser, and you can test it and the performance is OK—there is a slight risk that you can get problems [with XML communication performance].

When we first launched, Safari, just to mention one example, had very slow XSLT support. JSON is more native to JavaScript, and is slightly more efficient. We actually have our own [wire] format that's optimized for performance and compactness, because we have to deal with all kinds of browsers that can be running on an [Intel] 386 computer, on Windows 95. You don't really control those performance attributes.

We concentrate a lot on optimizing performance, even for very low-end browsers. When we compile, there are a number of different JavaScript and HTML files as output. Depending on your browser and platform, you might [load] a different file. We've done that so that we can have the absolute minimum code size for every single browser configuration. The Opera JavaScript file, for instance, might be slightly bigger than the IE JavaScript file, but that means that all your IE users will get, say, 10KB less to download.

Frank Sommers: It seems that by treating JavaScript as an assembly language for the Web, you were able to combine the best of both worlds: Great Java development tools with the deployment ease of client-side JavaScript. What's your take on other approaches to rich-client Web development, such as writing Ajax applications in pure JavaScript, or on JSF?

Bret Taylor: Looking at these technologies purely from a programming model perspective is probably not the best thing. What we like to think of at Google is, what is the best user experience? Ajax has a lot of potential to make the user experience better and more interactive. For something like Gmail, we really leverage Ajax for performance. We pre-fetch messages so that when you click on them we don't need to do any round-trips to the server. With Google Maps we dynamically download new map tiles so you don't need to re-download part of the map that you've already seen.

The optimal toolkit—and GWT is certainly not the best for every case—combines the programming model and the user experience most effectively. We tried to do that [with GWT], optimizing for things like download size, or how much can we reduce client-server interaction, and combined that with a programming model that hopefully is very familiar to Java developers.

For very large Ajax applications internally, we have a lot of momentum for GWT. Development tools with Java are so rich that using Java to develop these applications makes development easier in larger groups. The refactoring tools, debugging tools, and build tools, are so much more sophisticated in Java than [they are] in JavaScript that we see a lot of momentum internally.

We currently use GWT in a number of our own projects. GoogleBase uses it. If you buy a product with Google Checkout, you'll end up on a number of pages that were built with GWT. There are other less-known examples, and there are a number of internal projects that I can't tell you about.

But I see a role for pure JavaScript as well. Our three main programming languages at Google are Java, Python and C++, that's just the way Google has standardized internally. Every programmer has a different style programming, and every programming language has its value and different style. And at the end of the day, we put a lot of investment into our JavaScript tools as well, and we're very big supporters of Dojo and the OpenAjax Alliance. If the user experience is good, we're supporters of the technology.

Frank Sommers: Can you tell us about the recent release?

Bret Taylor: We had a release last week that supports development on Mac OS X. The hosted Web browser I described earlier didn't run on Mac OS X, and now it does. Now, you can develop your application on Windows, Linux, or the Mac, and you can deploy it on all browsers and environments that are in common use. It's one of the most platform-independent products Google has, and we're really proud of that.

We also did a number of performance improvements, particularly for the hosted Web browser. When you're doing the edit-debug-refresh cycle, it's about ten to twenty times faster. We did a lot of work on how quickly we can compile changes, and incorporated that into the hosted Web browser—some very sophisticated work by our engineering team.

Frank Sommers: What's the licensing of GWT?

Bret Taylor: The libraries and most of the code that you use to develop your application are released under the Apache 2.0 license. The compiler is closed-source, but is completely free.

Frank Sommers: How does a project like GWT fit into Google's overall business?

Bret Taylor: We have a few separate developer efforts. One is releasing APIs for Google's products. Probably the most talked-about one is the maps API that lets you incorporate Google Maps into your own Web pages. We have others, too, that we released in the past few years, such as the Google Base API that lets you put your listing into Google base very easily, we have the Google Calendar API that a number of people have written calendar syncing tools for, and we're really trying to open up all, or a lot of, our products so that they can be extended and improved by developers.

Along with that, we're focusing on things like GWT, or general-purpose developer tools that improve the state of Web application development. We have the view that what's good for the Web is good for Google. At the end of the day, the more people use the Web, the more searches they do on Google. We found that Ajax improved the state of our applications so well, and that it was a difficult thing for developers to get right, that we are really committed to releasing some of the technologies we use to make Ajax development work so that the state of Web applications get better. That's why we support a lot of open-source projects, because that's really the foundation of the Internet, and we want to continue to support that ecosystem.