10 May 2007 JavaOne – Fast, Easy or Beautiful – pick 3 when building with GWT
The Google Web Toolkit (GWT) session today was very interesting. Without personal experience using it I am not going to comment on it too much, but there were some interesting things that came out of the session.
Firstly, the GWT guys outlined the fundamentals behind their approach. It was interesting to see that their focus is on the end user experience, and for them that means speed and reliability. They are happy that they don’t have the most ‘gee whiz’ widgets if in any way they are not fast and cross browser compatible. To a certain extent, their compromise is to the ‘lowest common denominator’ however with the work they are putting in I am not sure that there are too many compromises. They are also big fans of static compilation. Not just because they like it, but because it allows them to better optimise the code produced. For them the optimisation allows even smaller downloads and faster execution.
The other interesting thing was their focus on the compilation process. For those that don’t know in GWT you write Java code (very Swing like) and the GWT compiler actually creates all the JavaScript you need. What I didn’t know is that it creates an include file specific for each browser and language in order to keep the client download size small. Also, in a recent release they have adopted a pretty funky image optimisation where all images in the view are merged into a single image. The code then ‘windows’ this large image to only show what it is supposed to. Why do this? Well according to them HTTP requests are expensive in terms of performance. By downloading one file once the browser is likely to cache this file well and subsequent visits or AJAX requests never have to download an image again. Sweet.
Another interesting point was their focus on testing. There is now a tool that allows the code to be deployed out to a number of machines and browsers to test performance.
They also talked up the changes in the last year, particularly in performance. Like the image compression above, they have done several other changes to create even more efficient code. They claimed performance improvements of between 30% and 80% over the same code of the year prior. Best part is that no changes were required in the application code, it was all achieved through better compilation techniques. Just get the latest version, re-compile and you are done! They think there is still ‘lots more low hanging fruit’, so it will be interesting to see how much faster it can be.
In their own words, they believe GWT is software engineering for AJAX. In the Java space it certainly seems like a compelling story and one well worth further investigation.
stephenc
Posted at 14:37h, 10 MayI have to agree that I think that GWT is potentially a big player in the web framework market. The test sites I’ve built are very easy to setup and there is a very low bar to entry if you are a Java developer. The main downside for me is the lack of support for Java5 – this is now out of the upcoming 1.4 release and supposedly aimed for 1.5 which means another 3 to 6 mths away. The main issue here is that if you are trying to “bolt on” a GWT framework on top of an existing Java 5 application that uses annotations (in particular I am thinking of Hibernate annotated POJO’s) then the compiler falls over and they are unusable – there are some work arounds but none that I’ve found that are very pretty.
However, once this is sorted I’m likely to be a strong advocate as you can build feature rich web based applications that look fantastic very quickly and you can leave most of the browser compatibility issues to the guys at Google who have the resources to deal with such boiler plate issues.
dgirard
Posted at 22:13h, 15 MayGWT is not compatible with Java 5, but it is possible to have the client part of your application in Java 1.4 and the server part of your code in Java 5.
xwarzee
Posted at 02:38h, 16 MayI developed a jumpstart application with a presentation part based on GWT in Java 1.4 and a server part with Java5. The presentation part (the implementations of GWT RemoteService) dialogs with the server part through web services, thanks to Spring/XFire. Thus, I was able to use full power of Java5 (generics, annotations) on the server part to annotate Hibernate POJOs and develop generic DAOs.
With Spring/XFire, you will be able to switch to simple method calls when Java5 will be supported by GWT without Java code changes in the presentation part 🙂
To publish POJOs as web services without Java5 dependencies (generics collections !) and to load collections (since Hibernate3, the collections are lazy loaded), I found BeanLib really helpful to populate all the attributes of POJOs. Then, the POJOs published as web services use only XML strings as returned values and parameters if required.
I agree it is anyway a little tricky if web services don’t make sense in your application use cases.
Xavier