Preface

In the middle of 2005, we noticed that something was different. The Web had reinvented itself, and terms like Ajax and Web 2.0 were being created to help define the new technologies and ideas. JavaScript tools like Scriptaculous, Prototype, and DWR were entering the scene, making it much easier to use JavaScript for interactive interfaces and making Ajax easier to employ. At the same time, Ajax applications, such as Flickr and Google Mail, were beginning to revolutionize the way users expected to use the Web.

We experimented with the new JavaScript libraries, but developing applications seemed more difficult than it needed to be. We also had difficulty seeing how to effectively manage a project using JavaScript—we were used to the ease of development that comes with typed languages, testing, and powerful IDEs with debugging capabilities. Sure, you can manage a successful JavaScript project, but the need to develop and maintain several different versions of code for differing browsers is a headache. Also, in our experience, it isn’t easy to find enough JavaScript developers who are aware of the necessary browser issues and nuances and who are also at a sufficient comfort level with production quality development processes to deliver a large project (compared to the number of Java programmers).

In May 2006, a news item from the JavaOne conference announced the Google Web Toolkit. It was described as a toolkit that let you write client-side code in Java and compile it to JavaScript. It was like Christmas, and we hurried to download and exploit these new toys.

We were early adopters, quickly joining in with the rest of the GWT community in test-driving this new tool. Each day, developers posted to the developers’ list the source code of widgets they had created. Everyone was trying to show what they could do and share their code with others. This led Robert to start the GWT Widget Library project on SourceForge. Before long, we were working together on the code for Adam’s EditableLabel for the GWT Widget Library. We worked well together, and we shared a huge enthusiasm for this new technology. When Manning asked if we would write a book, we jumped at the chance to share everything we had learned to date.

To paraphrase the first few paragraphs of this book, instead of taking tools to the Ajax space, Google has taken Ajax to the tools. We can now use fully fledged IDEs, and GWT manages all the messing around associated with browser differences. Just as important is the fact that by using Java and all the normal Java tools (IDEs, Ant, Maven, and so on), GWT fits into our development processes as a hand does into a glove, plus it supports internationalization and unit testing right out of the box.

Let’s be clear: GWT won’t solve every problem you have when it comes to creating Ajax applications, and some elements could be improved (now that it’s open source, it can only get better). But GWT takes a massive step toward maturing the process of creating and maintaining Ajax applications. We finish the book with the following statement, which sums up our view of GWT: “…we don’t even want to think about the amount of effort that would be required to program, let alone debug, any issues or perform maintenance across six different browsers for an application such as the Dashboard (developed in this book) directly in JavaScript.”

GWT has proven to be a viable alternative to pure JavaScript development. Each major release of GWT brings new features; and month after month new applications are being released by eager developers. We hope that through this book, we can share our enthusiasm for GWT and make it easier for you to get the most out of this technology.