Google Web Toolkit for Rich Internet Applications –A Java Programmer’s Experience

Recently, I have been working on porting a Struts and uPortal based legacy application to GWT. This work was initiated a year ago to replace an unappealing, non-responsive and slow user interface of the legacy application. Another key requirement was to make the client side technology stack lighter. Use of multiple client side technologies (Struts, uPortal, JSP, Tag libraries, Java Script, configuration files, CSS, XSLT) made it difficult to make even simple UI changes.

After initial analysis, it was clear that we needed to incorporate AJAX in multiple areas across the application. It was further decided to use one of the existing AJAX frameworks rather than writing AJAX “by hand”. After evaluating several AJAX frameworks, we selected GWT. Other AJAX frameworks like DOJO and YUI library are also good but they did not solve the above mentioned problems arising from a fat architecture and a complicated technology stack.

One of the primary reasons for selecting GWT was its unique approach to developing the complete application: both the client side and the server side components using Java. GUI development with GWT APIs is similar to Swing development and it is refreshing to forget JSP, JavaScript, and Struts and write everything using Java. I am very happy with experience so far and we have vastly improved presentation layer while retaining most of the service layer code.

With GWT, the AJAX front-end is written in Java that gets compiled into highly optimized Java Script. Developers do not need to write Java Script while end users are provided with dynamic and standards-compliant AJAX experience. JavaScript gets downloaded by the client browser at runtime where most of the client side processing is performed thus releasing the server side from handling presentation tasks.

I am impressed by the developer friendly features of GWT. Using Java in the presentation layer facilitates the use of design patterns and creation of reusable widget libraries. GWT’s approach to history management, internationalization, and service layer interaction is easy to understand and implement. I felt spoilt by the choice of available tools, default support for multiple browsers and ability to debug AJAX in hosted mode. I also noticed ancillary benefits like elimination of training on multiple technologies, reduced dependence on technology experts, and the overall speed of development.

I have heard arguments about Flex being a better RIA choice than GWT. I think this may be because some people may not be aware of other GWT widget libraries (like GWT-EXT) available today. Although GWT comes with a very good collection of useful and cool widgets but you can always use third party widget libraries which provide additional AJAX components like a special Tree or Grid component. We used GWT-EXT, a very rich widget library to achieve the desired functionality.

I found a few features missing – for example, there is no inbuilt support to load client side libraries on demand. Actually GWT loads all client-side libraries in client’s browser when the end-user accesses any module of the web application for the first time. So I think GWT may be a misfit for large enterprise applications. Also I faced problems due to lack of emulators for some of the Java classes like Calendar and our application POJOs contain Calendar objects. The good thing is that there are workarounds available to solve these problems.

I strongly recommend GWT if you are developing a mid size web application that needs enhanced usability and a desktop like look and feel.

Share and Enjoy