Google Health started to pick up speed around the time I first joined Google. A few of us had whipped up a prototype in our 20% time. GWT naturally came into the picture as we tried to decide what we would use to build our client infrastructure: hand-written JavaScript with other internal JS libraries, or GWT. We didn't jump right to GWT until we did our homework. We loved the concept, but GWT was fairly new back then. We were cautious about whether it was mature enough for a production-planned project like Google Health.
Since many of you are faced with these same decisions, I thought it might be useful to share a synopsis of that first email thread I wrote to the GWT team titled "GWT, to use or not to use". In it I included a link to our mock as well as 4 key questions:
Scott Blum from the GWT team responded that "in general anything you can do in HTML, you can do with GWT". Joel Webber, one of the founders of GWT, added "Looking at the your mocks... it appears as though you would want to fetch lots of information from the server during the course of interaction with the user, and to update both the form on the left and the results on the right interactively. I think GWT would be an excellent way to do this". To get a better feel for what GWT development meant, I created a sample project to test the waters. After exploring the widget library, I was able to build a functional prototype quickly. I tried a bunch of different widgets and found that they are easy to use and extend. The RPC calls were straightforward as well, and tied into the Servlet framework nicely. I was very pleased with the result of the prototyping.
Scott also confirmed browser support for "Recent versions of Opera, Safari, and Mozilla/Firefox; IE6+", which was satisfactory for us.
At the time, the i18n support was still in the works, but we were assured that it would arrive very soon. We were a little bit worried about how hard it would be but we were pleasantly surprised to learn that the implementation was really simple. All we had to do is to inherit the i18n package, create the constant and message classes along with their associated property files for all the strings, messages that need to be externalized.
The initial answer I got regarding our fourth question was "your entire application is monolithically compiled into aggressively optimized and obfuscated JavaScript. It's a "pay-as-you-go" model, code you don't call gets pruned", and "GWT uses a trick to allow its script to be reliably compressed, resulting in a 3-5 fold decrease in size". I had vivid memory of working on scripts to prune and obfuscate handwritten JavaScript code in my previous job, and how it required constant tweaks and tune-ups. As painful as it may be, performance tuning is a very important step for any large-scale JavaScript application. The initial download time and execution speed are crucial and greatly affect the user's perception of an application. As a skeptical engineer, I performed my own tests to validate these claims and test performance, initially and prior to launch, to make sure that the code was pruned, optimized and obfuscated. The results of this testing proved to me that GWT could live up to our expectations.
Finally, after receiving convincing arguments and techniques for creating a custom-cut Google Data library, the choice for which technology to use to bring Google Health to production was obvious, and the rest is history. My sample GWT project became the launch pad for the Google Health client infrastructure.
Of course we didn't develop the whole application without running into technical challenges. We grew our application as GWT itself was still growing up. There were times when we realized that some of the little details in JavaScript were not exposed through GWT. In most of these cases, we used JSNI to access lower level JavaScript functionality. At one point, we also noticed that as we continued to build the application the initial download time started growing as well. We analyzed all the requests and realized that there was cumulative latency introduced by each little icon, logo and other images that needed to be requested and loaded during the application loading. We used GWT image bundle to handle all the images and it considerably improved performance. Finally, in cases where we thought a certain widget should be further extended, we took one of a few approaches: first we checked for such a widget in the GWT pipeline; second we checked the developer forum to see if someone has already constructed what we need and contributed it back the open source community; third, we developed our own and contribute it back to GWT for potential inclusion in a future release.
Looking back today at a successful Google Health pilot and public launch after 2 major UI redesigns, numerous UI experiments including proof of concepts and user studies, it's hard for me to imagine accomplishing so much in last two years without GWT. We were able to do all the fancy JavaScript stuff in half of the effort it would have taken with handwritten JavaScript. We were able to write truly object-oriented UI code, refactoring and reuse were much easier, and leveraging IDEs like IntelliJ or Eclipse made UI redesigns much easier to absorb. GWT's compile-time elimination of dead code also meant we didn't have to worry about unused code that was still hanging around the codebase (of course it's best to do code cleanups every now and then), and we were also able to easily create unit tests for our UI code with GWT's integration with JUnit, which saved us lots of debugging time as our engineering team grew. It's been an amazing experience.
