Wednesday, June 13, 2007
Two weeks on GWT
So far using GWT has been a mixed bag. I am familiar with the typical GUI programming frameworks like Swing, and GWT fits right in with that model. Here's my quick pros and cons list after my short introduction to the framework.
Pros:
Pros:
- GWT programming feels right at home for someone familiar with Swing.
- Having used Dojo and GWT for AJAX, I much prefer GWT because of its seamless feel. Programing both the client and the server in a single language against similar interfaces just feels right.
- Your IDE helps you along the way (most of the time). For the most part GWT integrates well with typical IDE features like "find usages of this class" etc.
- The GWT compiler wants access to all source involved in the client side compilation. It is not sufficient to have the compiled class files available, GWT wants the original java source. This makes working with value objects from a service interface awkward since I typically do not package my service source for consumption by a later stage of the build. I cannot think why GWT needs the source, since all the necessary info should be available in the bytecode (especially since GWT does not support 1.5 features).
- The service call requires two interfaces, an async interface that the client interacts with and the sync version of the same interface that the service side implements. This reminds me of the EJB days with interfaces that had to mirror each other but were not connected. I complete understand why they did things the way that they did, but it just does not smell right. I think I would have rather had the service side implement the async interface.
- GWT does not support java 1.5 features. This includes the new(er) for loop construct! I think this problem would be solved if GWT operated off of the byte code, since much of java 1.5 was semantic sugar.