GWT and my experience

Coming from a backend / middle-tier Java Server background, UI and especially Web-UI is something that I never had a need to gain expertise or desired adding that to my skill set. Although it is something that I have architected as part of the overall system but the intricacies of it viz. “what is CSS 3.0 and float:left?” and so on were a complete mystery to me.

Recently, I thought of learning and discovering what some of my team mates experience when working on this part of the technology stack. After having undertaken to work on a sample web project- chose GWT. The reasoning behind choosing it is simple – Google maps and GMail, to name a few, are implemented in it as well as was inquisitive about deploying my codebase to just a web server with or without AJAX calls to a servlet container or a non-Java backend. GWT fit the bill exactly.

Went ahead and downloaded GWT, downloaded the GWT plugin for Eclipse and went to work. From the perspective of a Java programmer, these are my inferences:

  1. Getting started with GWT is easy, my first application was done in a jiffy. Debugging the client, deploying in development mode to the built-in engine, running it in chrome with the GWT plugin installed and examining the results takes the least amount of time as compared to any other web UI technology out there. Of course, I am comparing it with web UI libraries and not Web MVC frameworks as in Struts, Web Flow et al.
  2. Thereafter, introduced the MVC concept and that was homegrown. This is what I did:
    • Introduced the entry-point class with an Enum representing all the different screens in the system namely registration and login.
    • There was a controller for each of the screens – a LoginController for login and a RegistrationController for registration screen.
    • The entry-point created the screens by invoking the constructors that took in the respective controllers as arguments.
    • The LoginController is responsible for invoking the back end services. For instance: invoking the back end service for login (authentication).
    • The view which is the screen (for example the login screen) implements the model interface so that when the controller invokes the back end service, it can extract the details from the view (that holds the model data anyway). For this to happen, in an action listener (or equivalent event listener method), the appropriate controller method is invoked with the screen instance as one of its arguments).
    • If the back end service call is successful then the async callback is invoked with the result and that results in the appropriate view being painted (the term is from the days of AWT, remember that one?) or displayed.

While playing around with GWT, picked up a little CSS and HTML and the requirements of this exercise were met in toto.

Advantages of GWT:

  1. A quick way forward for a non HTML and CSS (also JavaScript) actor to dish out some web pages.
  2. A Java professional is able to dramatically reduce the learning curve with respect to generating a web presence and taking advantage of the event notification paradigm that is more familiar since that has been a cornerstone of Java AWT and Swing.
  3. In case you like a little more control of the HTML, you could use UIBinder or include HTML into GWT widgets directly (see HTML and HTMLPanel).
  4. These web pages generally work across different browsers.
  5. AJAX functionality is provided out of the box – the compiled code generates JS that takes care of that without the developer needing to write one line of code.

Disadvantages of GWT:

  1. GWT is not a framework for MVC based web development such as Spring MVC, JSF or Struts. It is a library for creating a web presence. You would need to incorporate a design based on the pattern (MVC) on your own. There might be open source frameworks that run on top of GWT but I have not had a chance to investigate any of those.