the bloggard

Google Web Toolkit (GWT), now in it’s second major release, has been around since 2006 (if not before) and I remember that it caused quite a commotion at the time, as it espoused the ability to create JavaScript based AJAX applications while programming in pure Java.

I was pretty interested in checking it out at the time but had little time on my hands and the proliferation of AJAX into the projects I was working on was pretty minimal in that perhaps one or two areas of the application leveraged the advantages of AJAX but it was far from being adopted application wide as the de facto client / server interaction model. In addition, many of the enterprise products I was dealing would have traditionally been slower in providing first class integration of newer technologies as a core product feature but were rather tacked on to fulfill customer requirements and sales & marketing demands.

I’ve had a little bit more flexibility in recent times in technology selection for new product development and have had the opportunity to use GWT and some additional libraries providing extended support for GWT and wanted to provide my insights in this blog entry and relate how what started as an evaluation of GWT ended in adoption of jQuery …

from 5,000 feet

At a high level, GWT is a development toolkit, which allows application developers write browser based applications in the familiar Java programming language, leveraging all the features available in a standard integrated development environment (IDE). In essence a developer can create a JavaScript based application in a cross browser compatible way using the Java toolkit provided in GWT.

Similar to programming in Java Swing or AWT, GWT provides a set of widgets or constructs such as a Panel, Button, Event, Listeners etc. via it’s Java library that a developer can code against analogously to a traditional user interface based application. The difference being that there is a pre-compilation step or GWT compilation step that occurs prior to the normal compilation step for server side code that converts the Java application code to JavaScript code in a cross browser compatible way.

and why do I care?

The use of Java in this way allows the standard features of a typical IDE to be leveraged while developing JavaScript applications:

1. Integrated debugging
2. Compile time syntax and error checking
3. Code completion shortcuts
4. Syntax highlighting

Writing a JavaScript application with any level of complexity can be pretty challenging at the best of times and most often what causes it to be this challenging is the lack of availability of the preceding features (particularly 1 – 3, as syntax highlighting is easily supported even in most text editors nowadays). In my experience, syntax errors are the most common cause of a lot JavaScript problems but once these are overcome, not having a properly integrated debugger can cause a lot of wasted time and effort at the most critical time in the project.

hasn’t this been done before?

Beyond FireBug, whose usefulness is unquestionable in any JavaScript development (or web development in general), I’ve yet to come across a comparable tool integrated with a traditional IDE. I’d be naive to think that none exist or that there are no extensions available to existing IDEs that can help solve these issues however I’ve not come across any that have gained sufficient penetration for me to consider them in a project. I’d be interested in any recommendations.

This to me is why GWT is so appealing as a development toolkit. Providing a solution to the issues mentioned above can add up to huge cost savings for a complex project and ease the longer term support and maintenance headaches that invariably arise as teams change and people grow into new positions. Having such a well know framework for development such as that provided by GWT / Java the addition of new people to the team can be more easily supported and more junior members can be supported more autonomously.

now, what’s the bad news?

In reality there are some downsides that should be considered when deciding on whether or not to incorporate GWT into your project, which I will cover in the following sections.

framework shortcomings

Like most frameworks GWT provides a set of core classes and widgets to code against and extend as desired, to support your custom requirements. However, the reality in frameworks pitched at the abstraction that GWT is pitched at is that most applications rely on additional third party libraries on top of the framework to provide the rich feature set that is needed in their application. In this regard, I would compare GWT for JavaScript with the Servlet Specification for Java. I think it’s fair to say that there are not too many applications being coded directly on top of the servlet framework, rather applications are being built on third party frameworks which sit on top of the servlet framework e.g. Spring MVC, Portlets, Grails.

It’s unlikely that the widgets, classes and server side integration provided by GWT will be adequate for companies evaluating the technology as a long term solution to their JavaScript application development needs. Understanding the feature set and the road-map is a key factor in technology selection for a lot of companies. Fortunately this  is addressed in two ways by GWT:

1. There are a large number of libraries available that extend the core GWT framework. The two most ubiquitous examples are Smart GWT and Ext GWT. A search for GWT libraries reveals a lot more besides, with varying functionality. Most if not all provide at least a free version with additional features being offered on a license basis. The features available and the pricing need to be understood fully before the selection should be made.
2. As of release 2.0 of GWT, Google has open sourced the toolkit allowing for the development community at large to extend the core functionality provided in the framework. This should spur additional contributions from the development community providing many of the productivity features that have been built to address their specific needs that can now be more rapidly released back to a wider audience.

page loading / rendering

My biggest complaint with GWT and even some pure JavaScript applications is when the entire application is coded in one “.js” file. Depending on the size of the application, these files can be very large (I’ve seen files > 1 MB!) which can cause initial response times of well over 5 – 10 seconds including browser download and the time taken for the browser to parse the respective JavaScript. In all but very few cases this is totally unacceptable.

Fortunately the GWT toolkit does allow a developer to split the application into separate modules to support loading the respective JavaScript on demand, however it is far from intuitive as to how this is done and the framework does not urge the developer down that path from the start. Instead, the intuitive approach is that most applications are developed as a single module up to the point where the initial response times become unacceptable and the team is forced to refactor and split the application up accordingly. The problem with this type of refactoring is that it’s much more expensive to do later in the project where it should have been planned from the start.

cross browser support is a moot point

Not that I want to undermine the significance of cross browser support, it’s just that as a feature (in my opinion) it’s become commoditized. It’s almost expected today that such frameworks are cross browser compatible. As far as I can see the majority of popular JavaScript libraries espouse cross browser compatibility (with the exception of IE 6.x in some cases).

Having said that the experience the team has had with this has not been all good. There were a number of areas where there were incompatibilities across browsers, particularly around layout and positioning. The good news however is that these were tracked down to CSS issues rather than JavaScript issues. Of late, it seems that CSS incompatibilities or inconsistencies are causing the most issues rather than the JavaScript compatibility issues. CSS is still fully in the hands of the design and development with the framework making no promises as to how it can help in that regard.

mixing presentation & code

One of the big advantages of GWT, JavaScript development in Java, is also the underlying reason for my second biggest complain in that it’s necessary to have all presentation layout in the Java code. For example, if you want to position a button on a page or render a table, you need to write all the necessary Java code to do just that. Not everyone may agree with me but in my opinion this is something software engineers having being trying to avoid for eons and although not pedantically incorrect it simply leads to bloated classes that are more difficult to read and maintain.

Fortunately, GWT 2.0, includes a feature known as the UiBinder, which addresses this exact problem and allows a developer to specify the layout and presentation using an XML based representation and even allows the interspersement of HTML fragments within the layout. In this way the user interface can be specified declaratively rather than procedurally as is the case in the current version.

reinventing the wheel

While the possibility of creating a JavaScript application in Java is appealing it must be considered that this will likely include full user interface specification, support for interactions with the user interface, the need to maintain state within the interface and supporting transitions between states. This is above and beyond any server side interactions as it must be remembered that there are few or no transitions between JSP / HTML pages in the GWT paradigm. As such there is an inherent challenge that arises in designing an application architecture which supports all of the preceding in a flexible and maintainable way.

Development teams have become accustomed to using existing libraries such as Spring MVC, to address these challenges. With the paradigm shift supported by GWT, the problem may be that teams will find themselves reinventing similar designs to support the functionality that they are used to, in the absence of first class support for similar frameworks in GWT.

other client side integrations

One particularly challenging problem that was faced was integrating an OpenID JavaScript library with GWT (specifically Smart GWT). In this situation, needing the ability to open a separate window outside of the control of GWT, supporting multiple redirects and finally returning control back to GWT and passing the necessary authentication tokens, was very difficult and an elegant solution was not apparent. As of writing the solution is still far from satisfactory, with a number of open issues that the team is still tackling.

What would have been quite easy to implement and integrate into a typical JavaScript web based application with a few lines of code was very difficult given the obfuscated nature of the final GWT JavaScript code after the Java code was compiled.

not all doom and gloom

GWT has some amazing benefits to it, particularly when you consider the integrated debugging support. This alone could save a project on the order of man-weeks when issues are encountered and depending on the complexity of the project. Apart from making complex JavaScript application development accessible to Java developers, GWT does a fantastic job of optimizing your JavaScript code.

After the GWT compilation step, multiple “.js” files will be created targeted on a per browser basis. If the application has i18n or l10n requirements, GWT will optimize it the JavaScript files so that they can be downloaded on a per locale basis. This type of optimization can be difficult and costly to support in an ongoing basis and require a lot of custom scripting so should be another key consideration for projects considering using GWT along with:

1. Server side integration – what level of support above and beyond the GWT RPC support does the library provide. Some libraries such as Smart GWT Enterprise Edition (Smart GWT EE) provide excellent data binding support with server side objects and save a lot of development time. However there is a cost usually associated with such libraries.
2. Widget extensions and theme support – What level of support does the framework provide for implementing a custom theme most efficiently and what additional widgets are provided within the framework above and beyond those provided by GWT e.g. list grids, cascading drop downs.

summary

In general I’d be reluctant to use GWT for a large scale project in the near future, not specifically due to the reasons mentioned above but more simply due to the alternatives that are available. I’ve been fortunate to use the jQuery JavaScript library more recently, Ext JS being a similar JavaScript library (I have not used) and my experience with it has been first class.

As a native JavaScript library that is integrated with your web pages (JSP / HTML) in the traditional fashion, a lot of the concerns mentioned above are addressed:

1. Page loading – JavaScript is intuitively spread across the pages it is needed
2. Cross browser support – jQuery (and Ext JS) espouses the same cross browser compatibility
3. Layout / presentation separated – In the traditional manner your web pages are built in JSP / HTML with JavaScript supporting the AJAX based user interaction and your server side code coded as usual
4. Easily integrate other libraries – Having control over and access to the JSP / HTML page allows you to easily integrate other libraries and control the flow between these libraries more easily
5. As to the two points on “framework shortcomings” and “reinventing the wheel”, one need only search for jQuery plug-ins to see the vast amount of third party plug-ins available to extend the base jQuery library.

The downside to jQuery and similar libraries is that they fail to support the key productivity features I originally presented as advantageous in GWT. While this would be nice to have, I find that the amount of JavaScript code being written is minimal enough to not require extensive debugging as the code focuses solely on discreet user interactions with page elements and the invocation of server side ReST based calls. The need for debugging in these situations is minimized in comparison to using JavaScript to layout and render the entire application while managing all user interactions and state transitions. It might be said that GWT solves the problem it itself has introduced by allowing full application development to be done in Java.

In the interest of disclosure, however, it’s necessary to admit that since using jQuery, I have wasted a noticeable amount of time hunting down some bugs which the IDE could easily have highlighted for me. Even with this in mind, the benefits of jQuery still outweigh the disadvantages for me in comparison to GWT.

To wrap things up in GWT’s favor, with the 2.0 release, a number of my concerns have been directly addressed although I have not had the opportunity to test the assertions put forth in the release notes. It’s definite that GWT 2.0 provides a much better framework that the 1.x version and developers trying it for the first time or those upgrading their projects may well find it to be the solution to their problems. For my part, having used jQuery for a number of weeks now, it will be a difficult transition to return to GWT and see how it shapes up but it is something I hope to find time for in the future. Until then, it’ll be jQuery all the way.