preface

Since the first edition of this book, the Google Web Toolkit (GWT) has grown, transformed, and emerged from a promising toolkit for web applications into a toolkit that truly supports 1) developers and managers in delivering web applications that can push the boundaries of the possible and 2) the application of well-tread engineering principles (deliver better user experience while reducing your development/maintenance costs).

This second edition of GWT in Action builds on our view of the first edition. It’s fully updated to look at the latest version, 2.5, of GWT, covering all the new techniques and tools—we even take a sneak look at the experimental items (such as super dev mode and the Elemental library). Perhaps the largest change between editions is that each technique is demonstrated with individual examples, rather than the monolithic example from the first edition. We hope this allows more focused examination and offers a simpler Ctrl+C/V mechanism to get those techniques into your own applications.

We said back in 2005 that we had noticed the web was reinventing itself with terms such as Ajax and Web 2.0 being created to help define the new technologies and ideas. As time has gone by, snippets of those techniques are on most modern websites—few websites require a page refresh to the server when updating information nowadays. Some sites have even harnessed the techniques in more depth and become full web applications, for example, Google Docs.

Now, in 2012, we stand at the beginning of the next reinvention, one that will further push the complexity of web applications. As we move toward the “cloud,” users will begin to expect web applications to be equivalent to the desktop ones they’ll be replacing. As more people gain access to smartphones, tablets, and related devices, there are opportunities to harness HTML 5 to provide web applications giving the same functionality as native apps, but you only have to write once rather than per device. These applications must be more robust than ever and will need the stability, speed, and responsiveness that at least matches native applications, if they’re to be taken seriously.

To reach that point, we’ll see a maturing from ad hoc web development that includes a sprinkling of Ajax toward the use of solid, well-tread, and proven engineering techniques that are commonly available in desktop development—such as applying architectural patterns such as MVP as well as harnessing dependency injection. At the same time, the flexibility of design, so well established in the web with separation of functionality from styling, needs to be maintained and harnessed.

But there are still the same challenges in the development world that we saw seven years ago around how to effectively manage a project using JavaScript—where we’re missing the ease of development that comes with typed languages, testing, and powerful IDEs with debugging capabilities. As we said in the first edition, it’s possible to manage a successful JavaScript project, but the need to develop and maintain several different versions of code for differing browsers is a headache, even with the use of modern libraries such as JQuery and the like. We can add to that the additional headaches we’ve experienced when trying to maintain all those versions over the lifecycle of the project, especially in the maintenance phases.

It also remains, in our experience, a challenge 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).

Step forward the latest versions of the Google Web Toolkit. GWT provides the support necessary for industry-grade techniques—event busses, the model-view-presenter (MVP) pattern, together with a reference implementation that can be built on activities and places, as well as the ability to harness dependency injection through Guice/GIN.

We get access to efficient paging through large datasets with cell-based data presentation widgets and can harness Editors to ensure that updates in UI items are automatically reflected in the model—and if that model is stored on a server, we can batch together updates to increase efficiency. Generators can be employed to minimize the amount of boilerplate code a developer needs to write and get it generated automatically at runtime.

GWT handles browser differences for us, and the compiler is aggressive about code removal to ensure the download is as small as possible for the user. Using GWT’s code-splitting approach together with bundling resources further increases the speed of downloads and efficiency—smaller and more efficient downloads all increase the user’s experience.

The toolkit allows us to separate the user interface from functionality by using the declarative UiBinder approach. CSS styling can be applied to all widgets to give the style needed, and it’s also possible to have some primitive themes, three of which are built in; beyond that your designer is free to apply the look you’ve agreed upon.

Because we’re developing in Java, we get access to all the Java tooling that’s available as well as robust IDEs in which to develop and debug. We can harness Ant and/or Maven to build the application and use Hudson to perform continuous builds and drive automated JUnit testing, ensuring team development quality is measurable and actionable. GWT’s development modes (original and super) enable us to user test in our browser of choice while debugging live in the IDE. There’s much more to say about that in this preface!

Let’s be clear: GWT won’t solve every problem you have when it comes to creating rich web applications. But GWT takes massive steps toward maturing the process of developing and maintaining Ajax applications. Couple that with a strong architect and development processes, and you can push those web application boundaries while being sure to excite and engage the user—just look at Rovio’s very popular Angry Birds version on Chrome, which is written in GWT (http://mng.bz/xbYP).

The first version of this book summed up by saying, “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 Dashboard [the monolithic application in the first edition] directly in JavaScript.” That view hasn’t changed, except to say there are more browser combinations, and the latest version of GWT brings more industry-grade techniques to the table to help us.

GWT has proven to be a viable alternative to pure JavaScript development. Each major release of GWT brings new features and bug fixes yet leaves relative stability to legacy code. Because it’s open source, you can contribute your own patches or see if patches in future releases are going to be helpful with any issue you might be having. With a wide user community it’s also easy to get answers to problems.

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.