Web App Design With Google Web Toolkit (GWT)

I’ve been exploring Google Web Toolkit (GWT) for a little more than six months now.  I’m in the process of a rewriting an older web application, which was developed based on more of a traditional architecture – with forms and form handlers.  It was written in ColdFusion and Java.  The CF layer is used as more of a scripting language, with most of the work done by several Java class libraries built for the app.

While using GWT I’ve started to experience a change in how I think about the design of web apps specifically built in GWT.  In particular, the management of application state is quite a bit different.  That leads to a different way of executing various actions, which would typically be persistence related (ie. reading and writing to a database).  I would be curious to hear feedback about this, particularly from other GWT developers.

First, let me review how I think of “traditional” web app development.  We all know that HTTP is stateless.  In other words, one page knows nothing about prior or successive pages served by the web server.  Fortunately, there are cookies and sessions to circumvent this limitation.

For purposes of discussion, let’s use a bookstore web app as an example.  Assume the online bookstore allows books to be browsed and purchased.  A shopping cart stores purchased items.  The bookstore also includes informational material – say on authors and publishers, etc.

With the bookstore, information typically needs to be remembered when a user visits.  For example, the collection of books in the shopping card must be remembered until the user checks out.  Typically, this is done in session variables.  The session variables are actually stored on the web server (and managed by the application server).  Each user has there own set of session variables.

It would be possible to build a web app without session variables.  One way is to simply store all state on the URL.  For simple apps this isn’t too difficult.  For more substantial apps it can lead to some ugliness in design.  For example, consider the bookstore shopping cart.  The following could appear in the URL to represent books in the cart:

http://www.mybookstore.com/…/*.html?booksincart=123,456,789

Note the part after the question mark.  The “booksincart” argument is a list of book ids.  This would have to appear as part of every URL in the online bookstore.  It proves to be rather ugly to implement.  Fortunately, session variables provide an easier way to store information in a stateful way.

With GWT, I am beginning to see an alternate way to store state.  A GWT app appears, from the programmer point of view, like a Java app that runs in the browser. It is really Javascript (and that is part of the magic of GWT), but conceptually think of it as a Java app.  Java apps can store all sort of variables – global variables, class variables. static variables.  I am learning that this is a great way to store application state and it replaces the need to store state in the session.

Compare a “traditional” web app with a GWT web app.  A traditional web app stores state in the session.  The actual session data resides on the server.  With GWT, state is stored in the app, which is on the client (in the browser).  This is a bit of a revelation for me.

The location of app state (on the client) then leads to a change in how I think about performing actions (on the server).  The server side operations (ex. save cart or place order), are stateless.  The client has to pass all state to the serve (or RPC).    This can even include the user, which is typically store in a session with a traditional web app. The operations then become very web-service-like in form.

Another way to think of this is going back to the comparison with a traditionally designed web app.  To get rid of most session variables, one could store all state on the URL (as discussed above) in arguments.  GWT could be thought of as a much more convenient way to store application state.  A well designed GWT provides for better conceptual design and state management.

Where are the Java Applets?

I’ve often asked myself why Java Applets are not more prevelant. HTML is relatively static. Even with CSS, web pages comprised simply of HTML are not very interactive, especially compared to desktop applications.

The developer community is very creative. A variety of technologies, methods, and tools have been utilized to bring life to HTML. Flash, Javascript, AJAX, and SVG are growing in popularity and add a richness and interactivity to web based apps that approaches desktop apps.

Why has the Java applet been left in the dust? I have a few explanations.

First, there is a lack of understanding in the proper usage of the Java applet on a web page. A web page is not a desktop application and the techniques of building Java standalone (desktop) applications do not carry over to web apps. Java user interface components and frameworks have advanced nicely over the years. SWT and Swing can be used to create desktop apps that are as clean, crisp, and visually appealing as native desktop apps. However, SWT and Swing have little use in a Java applet. And that is the approach many Java developers take.

The correct mindset is that of the Flash or browser plugin developer. At their disposal is a rectangular region of the page. They can do whatever they want in that space. To use Swing or SWT there – as it would be used on in a desktop app – is generally inappropriate.

Second, web developers that focus on look and feel are typically not software engineers. Software engineers gravitate towards Java. Designers gravitate towards things like Flash, CSS, and AJAX. While beautiful UIs can be built with Java, it is simply not the tool of the designer. Perhaps JavaFX will address this.

Finally, I believe the use of Java applets are underestimated. There are web sites that utilize Java applets, but they are not easily recognized. Applets don’t look like Swing or SWT apps, so they go unnoticed. These sites are using applets properly. They are not trying to stick a Java desktop-like component into the middle of a web page.

I would like to see Java applets utilized more. From the perspective of a software engineer, I prefer the Java applet. It provides a great deal of control, allows me to do quite a bit (in a rectangular region of a web page), is very robust, and performs extremely well. I generally avoid heavy Javascript because it is unpredictable across browsers. I’ve noticed that sites utilizing heavy Javascript tend to also have performance problems. So, while Java applets have plenty of advantages, it simply may not be the tool of choice.

RELATED
Applets reloaded