Pros and Cons of Google Web Toolkit, Part I

I’ve been using Google Web Toolkit (GWT) off and on for the last 4 years (nonstop for the last 2), and was going over my experiences with a friend recently. GWT transpiles Java code into Javascript, allowing you to effectively write Java for the browser. There are some definite pros and cons to this approach, here are some of my own thoughts on the subject.

[EDIT This blog post is just about my own personal experience. Recently Vaadin put out a very nice set of infographics about GWT which covers a more statistically significant view of the strengths and weaknesses of GWT since it surveyed many GWT developers.]
 
In this post we’ll review the advantages. The advantage of GWT falls into two main categories: the fact that you’re using Java, and the capabilities of the framework itself. Let’s start with the first of these.

Because the front-end code is written in Java, you can leverage the ecosystem’s very mature IDEs such as Eclipse and Netbeans. You can use the same IDE to develop the front end and the back end, providing a seamless end-to-end development experience. The same is true for debugging - the debugger steps from front end to back end and you never have to leave your IDE. Other big advantages of using a mature IDE include refactoring support, functionality to find usages, and other code navigation.

You can leverage language features not available in Javascript directly, like a built in module system (Java’s packages). For large projects, it is easier to use modules to manage one million lines of Java than one million lines of Javascript. Support for unit testing in Java has been first class for many years with JUnit and TestNG. Javascript does have unit testing capability (say, with Jasmine), but I don’t have the impression that unit testing in Javascript is as widespread or easy as it is with Java.

Finally for the “you’re using Java” aspect: you can leverage Java developers. For a small software shop that doesn’t have the resources or needs for a pure front end development team, it makes a lot of sense to make use of the skills your developers already have. I have seen several workplaces where this was the case, and it has generally worked out pretty well, making efficient use of existing development resources.

The other advantage of GWT lies in the capabilities of the framework itself. GWT as a framework doesn’t do anything that you can’t do with the right combination of other Javascript libraries. But as an AJAX framework, GWT pulls together a cohesive set of functionality for building a RIA and gives it to you out of the box. For example: AJAX handling (actually multiple communication techniques: GWT-RPC, RequestFactory, and direct HTTP requests), history and place management, templating system with UI binder, form binding, and internationalization.

In conclusion, GWT is a mature and proven product, it is still being actively maintained and used, and it provides a lot of advantages to the software shop where it’s a good fit (say, a small team of Java developers who don’t have front end developers). As for whether or not GWT is always a good choice: As usual, it depends. In the next segment we’ll look at some of the disadvantages and see when you might not want to use it.