Technology adoption is an unpredictable process - part theater, part academic review, part marketing. In Java it is especially confusing becuase we have so many different “channels” to watch for new anouncements, there are conferences, there are web sites like Slashdot and TheServerSide, there are a zillion personal blogs like DHH, and O’Reilly’s Radar. An interesting technology might generate a huge buzz one week only to see this buzz fall off as people notice that the product wasn’t ready for prime time.

For a product to make it into the mainstream, early adopters have to like a product enough to undertake the often impossible task of convincing more cautious developers that new technology X is worth adopting. Technologies such as Hibernate or the Spring Framework take years to become established products. Some products, like Maven, have a hard time becoming established because they either lack sufficient documentation or have difficulty challenging well established products like Ant. I’m interested in this blind spot in the process, the time between the buzz producing introduction and early adoption to large-scale adoption usually takes months to years, and is difficult to chart because, in many ways, it is viral. HIbernate didn’t take the world by storm as much as it slowly reached a critical mass of self-sustaining adoption. A failed project like OJB certainly generated a buzz at one time, but it failed to make good on promises - in that case early adopters actively discouraged others from using it in favor of Hibernate. Turning our attention to the Google Web Toolkit (GWT)…

Where is GWT in this process?

GWT seems to be in the middle of this early-adopters stage. The initial buzz has worn off, we saw a flurry of articles and blog posts about GWT, and it appears that we’re waiting for this first class of GWT adopters to report back on experiences with the GWT. We’re waiting for the first public site to show us what is possible with the GWT. My more cautious colleagues are avoiding it altogether, actively disparaging it as a bad idea altogether. Risk averse developers tend to criticize most new technologies until they have been demonstrably proven to work in a real-world situation - “Maven ‘Sucks’ until they see that IBM is using it, etc”. Those developers that have the ability to take risks are taking the framework out for a test drive. Of these early adopters one has sworn it off completely as inappropriate for his organization, “It reminded him too much of Swing”. Another colleague has embraced the idea in principle, but doesn’t have the time to integrate it into his existing web application. In terms of adoption where is the Google Web Toolkit? What is the experience of the early adopter crowd?

To answer this question I spoke with Michael Podrazik of Grassroots Technologies, a consulting group based in New York City. Through his work with Grassroots, Michael has been using the Google Web Toolkit (GWT) for a new web application currently under development. In the following interview I asked him to communicate his own experiences with this product in an attempt to help others currently considering the GWT. I specifically asked him for an objective opinion of GWT, and to describe, in detail, the challenges he faced when developing with the GWT framework. Hopefully, this information will help you decide whether or not GWT is the right choice for your projects.

Read on, read the interview and share some of your own real experiences with GWT in the comment thread.

The Interview

Q: What made you choose GWT?

Michael: I subscribe to the Google blog, so I heard about GWT the day they announced it prior to JavaOne. After reading the documentation I became intrigued by the approach so I downloaded the ‘kit and started playing
with it.

I had just begun a project to replace a legacy Access/VBA desktop application with a webapp. The specs call for some Ajaxian features on the UI side so I thought I’d give GWT a shot. I figured that so long as I kept the architecture abstract enough I would be able to swap out the GWT layer for a more traditional webapp framework should GWT be too bleeding-edge but so far I’ve been very pleased.

Q: What challenges did GWT present? Did you design you web application around GWT? Did the GWT challenge your ideas about web application development?

Michael: You really can’t think of GWT as a webapp framework but more as a UI library with RPC and object serialization support. Because of that you need to change your assumptions about project organization, package structure, etc. We have a great deal of experience developing Java server applications with rich-client user interfaces in Flash/ActionScript, C++ and Director that speak XML to the server-side. The GWT metaphor is almost identical to that, so thinking about the project in those terms, (separate server and client applications rather than a monolithic webapp), is fitting.

Working in that direction, you need to draw a line between what work is going to happen on the client side and what on the server side. I believe a good philosophy is to keep as much on the server as possible so that the client only has to deal with the presentation.

You need to think about the design of your service interfaces, such as how granular each operation needs to be and what the efficiency implications are. Also what the caching strategy will be as far as keeping state in the client, how that will jive with server updates, but this is probably old-hat to a lot of Java developers…

Oh, and you can’t use Java5 syntax on the client code but that’s not such a big deal.

Q. What do you mean? You can’t use Java 5 syntax in GWT specific classes or in your web application in general?

Michael: You can’t use Java 5 syntax in client side classes. We are using many Java 5 features on the server side, but any code that will be translated to Javascript needs to restrict itself to 1.4 compliant code.
This also covers some classes that you actually use on the server, however. Since the RPC framework allows for the serialization of user-defined data types, this means that you’ll have a class that has been translated to Javascript instantiated in the browser passed as an argument, (or a return value), to a server-side RPC service implementation. In your server code you’ll be working with the same class but of course a compiled bytecode version of it.

This presents a choice as to how tightly you want to couple your domain model to GWT. What we decided was to keep value objects implementation-agnostic so as to avoid “infecting” the API and persistence layers with beans implementing GWT’s IsSerializable interface.

For example, on the server side we have a user modeled with an IUser interface that itself extends IPersistable. The GWT service implementations accept and return GwtUser instances that implement IsSerializable and copy the values back and forth to a server-side POJO using commons-beanutils.

It could be argued that this is an unnecessary complication but I felt that the little bit of extra busy work would give a cleaner separation of tiers. We could ditch GWT at any point and switch to SpringMVC or Struts or whatever without having to worry about repercussions “deeper” in the codebase.

Q. How did you overcome the fact that GWT had a Maven 1 plug-in but no Maven 2 plugin?

Michael: I initially attempted a port of Robert Cooper’s Maven 1 plugin, but soon after discovered this post by ’shinobu’ on the developer forums. I took that code and modified it slightly to better match our environment and it works pretty well for compilation.

It doesn’t launch the hosted mode, but to be honest I haven’t really been using that so much. I’ve incorporated the plugin mentioned above with the Jetty6 plugin and I find that this approach has the two advantages of 1) a faster iteration cycle (hosted mode is pretty slow to load) and 2) you’re having the same experience in development as users will once it’s in production so you can potentially catch problems much faster.

Q: What were your initial impressions of the codebase? Have you looked at the GWT codebase?

Michael: I haven’t dug around too too much in the source. I did look through the rpc package a bit because I wanted to make sure that I wasn’t going to break anything with the strategy I’m using on the server, (front dispatcher servlet routing RPC requests to Spring-managed GWT RemoteServiceServlet instances). I’ve also looked some at the UI classes because I was curious about the “native method” implementation. It’s certainly an interesting approach. Frankly I’m amazed that it works at all never mind how well it really does.

Q: Have you found any occasion where GWT produces Javascript that A.) isn’t cross browser compatible? or B.) Contains errors that must be debugged manually?

Michael: No, and that’s the truly amazing part. Cross-browser Javascript development is a PITA and GWT really manages to shield you completely from it.

I have had a couple of occasions where things didn’t look the same on Firefox and IE but it turned out to be differences in their CSS support and nothing to do with GWT. I did also have a couple of Javascript errors but they were due to variables not being initialized that was pretty quick to figure out and didn’t require a laborious debugging cycle. Most of the work that has been completed so far has not been all of the UI components so perhaps that will change when we really get in the thick of that, but so far I don’t have many complaints.

Q: Does your team consist of people who are more comfortable with Java or Javascript?

Michael: Java definitely, but there are people on the team who have JavaScript and ActionScript, (which is kind of a super-set of JavaScript), experience as well.

Q: Have you discussed the use of GWT with a designer? What was the designer’s input?

Michael: I haven’t. Luckily the project really is a Web-Application and not simply a website with dynamic components. There are wireframes, and I’m sure we will get to a UI tweaking stage with the relevant people but up till now we’ve had a pretty free hand to interpret the wireframes.

What I can’t really speak to yet, and what I think you’re driving at with this question, is how capable is it at implementing arbitrarily-complex very design-rich interfaces. My gut feeling is that you should be able to create your own widgets with any kind of complex internal layout, but I’m not sure what would happen if you need the pixel-precision that tends to come with trial and error HTML/CSS tweaks.

If all else fails you can drop down to the “native” API or else simply keep parts of the design outside of GWT. You can certainly do that but you’ll lack the programmability of those areas without explicitly building hooks yourself.
It’s interesting though that the trend in design of AJAX-enabled sites seems to be for very clean, simple interfaces. That’s certainly a welcome trend for anyone who’s put their time in mangling HTML tables to achieve some effect or another.

Q: All in all, what is your advice to someone considering GWT? Would you recommend it? What is your objective opinion about this technology? Thumbs up or thumbs down?

Michael: A thumbs up for now. We are still in the early stages of development and figuring things out day by day so I don’t want to claim that it’s perfection or won’t turn out to bite us in some unforeseen way down the road. That said it allows for some pretty compelling application architectures. It really is just like writing a desktop application in Swing or other UI toolkit.

We are generating the entire UI using GWT based on a Controller and IView “screen” or “page” implementations. There is literally *NO* HTML beyond the GWT module import.

That is a very significant departure from almost all mainstream web application paradigms, but if you are comfortable with UI programming it completely abstracts AJAXy/DHTMLy behavior into a very friendly and extensible API.

I guess I would say that if you do most of your web projects with something like PHP, ASP or other template or page-centric language then you may have a bit of a learning curve. If you are already an experienced Java programmer then you’ll probably be able to jump right in without much fuss.