Tuesday 8 May 2007

Tech Review: Google Web Toolkit

I’ve been working with the Google Web Toolkit for a while now, and thought it would be good to share my impressions of GWT so far.

Just getting my thoughts together on this, I was struck by some similarities between current AJAX development techniques and software development at the start of my programming career. It’s funny that almost 20 years later, AJAX developers are still struggling with the same problems that we had developing DOS TSR’s in assembly language.

  • Threading. The browsers JavaScript code execution model is single threaded and largely event driven. (A user clicks on something, your code handles that event etc) So, if you need to do continuous background processing, you will need to set timers and execute your code periodically in response to these events. The browser does provide some support for multithreading, e.g. a video or sound clip can be playing while javascript events are being processed, but from a JS developers perspective its single threaded.
  • Code Size. OK, unlike the old 640k limit which existed for DOS systems, there is no real technical limit on your AJAX application’s code size. The real limit is that excessive code size means the site takes longer to load which can mean your users going somewhere else. It is also more expensive to host.
  • Collections. With Java/.NET the platform provides great support for Lists, Hash Maps for storing and retrieving objects, it doesn’t come out of the box in the AJAX world.
  • Language choice. Server side developers have plenty of choices, including JEE, JSP, ASP, .NET, PHP, Ruby etc. Client/Browser UI developers really only have one choice. On the browser, you really only have JavaScript if you want to support all browsers.
  • Debugging support is very poor compared to developing traditional applications in C#, Java, C++ etc. Full source level debugging, ability to set conditional breakpoints etc have been standard for years when developing traditional applications.

These problems have been solved many times before for Windows, Linux and Mac application programmers.

On the plus side, the browser provides great features for programs like garbage collection, page layout, image rendering, multimedia support, CSS syling, http/s communications etc. But I thought that before looking at GWT, its worth mentioning that, from a developers perspective, there are limitations with the browser as an application platform.

Essentially, it’s user demand that any new application must be accessible via a single click on their browser that makes the browser the leading application platform today.

Aside over…

With GWT, you code in Java and GWT converts this code to JavaScript to execute on the browser. GWT also provides a set of base classes for creation of common UI elements, such as Radio Buttons, Images, Labels, Tables, PopupPanels etc. The base classes are a very thin abstraction layer over the browsers DOM. And also a set of classes which wrap the XMLHttpRequest object to simplify server interaction.

Learning Curve. There are a number of GWT books published which should help get started. But if you are a Java programmer who enjoys experimenting with different technology, the learning curve isn’t that tough. Once you get your project running in Eclipse and can run your code in hosted mode, then you are well on your way. The code base for the UI classes is small enough understand within a few days. The programming model is like Java Swing, but it also maps closely enough to AJAX programming. Not too surprising, as both are very much event driven. A good understanding of DHTML and CSS would help but isn’t essential to get started.

Productivity. I like to be able to stay away from browser quirks if at all possible. With GWT I find that I don’t have to test browser compatibility as much as if I was doing pure JavaScript. The other major productivity boost is in refactoring. With web development, often you start out with a basic prototype for the page layout, user interface and choices. The pages usually goes through a few iterations as trial user feedback is incorporated. The strong type checking inherent in the Java language and the refactoring tools in the Eclipse IDE make it much more easier to refactor the code to suit the new interface. The compiler will pick up most of the errors whereas when refactoring JavaScript the errors will only on execution.

Code size. The GWT java to JavaScript code converter minimizes download code size by minimizing white space, mapping function and variable names to their shortest possible values, and by producing browser specific versions of the code, which are downloaded after the start-up script figures out the browser type. I’ve found that the converter is quite smart in that it wont include java classes that are in the same package but are not referenced by the application code. As you start to add java code, download sizes increase but in a predictable manner. One thing I would advise is to double-check that your application is complex enough to warrant GWT if file download size is a serious concern. If, for example, you have a simple GWT app which creates an single image element and does something simple when the user clicks, the download will be almost as big an application that does a lot more. This is because classes like com.google.gwt.user.client.ui.ClickListenerCollection extend java.util.Vector and so the code for this class must also be converted and downloaded to the browser.

Production Ready. GWT is certainly ready for production use and for complex applications.

Application Updates. Your application is going to change over time, which will mean changes to server side code, Javascript, CSS etc. This should be easy, right? But browser bugs and user caching settings may result in cases where some old versions of your DHTML/Javascript is active on some browsers after your servers have been updated. GWT provides clever support to ensure this doesn’t happen by first tagging a parameter at the end of the main module include file and ensuring the filename of each included script is different for each version, to ensure its not cached. Simple but it works, and nice to see it’s taken care of automatically.

Services/Server Communication. GWT provides out of the box support for developing Java services that can be invoked by your GWT client code. One of the strengths of the toolkit is the simplicity of doing this.

Styling and CSS support. Its an area where I think the GWT team needs to rethink their approach. Basically, each ‘widget’ type (table, horizontal panel, vertical panel etc) is automatically set up with their own style name e.g. gwt-html for a HTML element. This Nub Games blog entry provides more information. At this stage I think the library would be better off not having default style names for elements, as unless the application is very simple, the same elements will require different styles anyways. I have found that IE 7, although its much better than IE 6, it still not 100% CSS compliant as regards selection of the correct style descriptor where style elements are inherited from many different parent elements. My feeling is that it will take a while for best practice to emerge in this area with GWT.

Appearance. GWT isn’t a simple way to add complex graphic effects to an existing web application; there are other better libraries out there if your main effort is going to be creating impressive visual effects on your pages but the overall essence of your application is each click should load a new page. GWT provides a standard set of UI widgets, which are functional, can be customized by CSS. Its not that suprising as Google’s applications are deceptively simple from a users perspective. GWT shines where you have a requirement for lots of business logic to be deployed and invoked within the browser in response to these simple standard controls.

JavaScript integration. I have used this if there’s a JavaScript library or widget that I want to include in my application, mainly for visual effects.

Code Reuse. There is support for inheriting code from third party libraries and indeed there are plenty of third party libraries already out there. If your server side uses Java, the same validation classes could be re-used to do client side checking for instant user feedback, and also reused on the server side for security. I don’t want to oversell GWT for code reuse, where your UI elements could inherit from some third party elements. Its certainly possible but I think it will take a while for quality third party components to emerge. One third party component i have used and recommend is this Simple XML Parser.

Debugging. ‘Hosted mode’ provides some support for hot code swapping but the logging support is worth it by itself. GWT.log output is displayed on the hosted mode container. The com.google.gwt.core.client.GWT class is treated specially by the java to javascript code convertor, which removes GWT.log calls when generating ‘production’ code.

Cross Browser. If you stick to the provided GWT UI elements, it just works!

Tip: Think twice before using a logging framework around calls to GWT.log. If you must do this ensure that the compiler/javascript code generator is optimizing these calls out to minimize your deployed code size and increase the responsiveness of your application.

Heres a simple example. The java code fragment contains an inline call to GWT.log plus a call to a method that wraps the logging call and logs. One would expect both calls to be removed by an optimizing compiler, hey the variables defining the logging behaviours are declared as final...

myWidget = new NewPagePrompt();
GWT.log("A call to the GWT log, note how it has been removed from Javascript", null);
log(msInfoLog, "Some Log message for Page number =["+pageNum"]");
}
private static void log(int level, String s) {
if (msLoggingLevel>=level)
GWT.log(s, null);
}
private static final int msInfoLog = 3;
private static final int msWarningLog = 2;
private static final int msErrorLog = 1;
private static final int msLoggingLevel = 0; // Set logging to off

But here’s the generated javascript for this java code fragment.

dH = bH(new cH());eH(fH,'Some Log message for Page number =[' + tG + ']);}

function eH(gH,hH){oG();if(iH >= gH);}

First, you can see how GWT minimized code size by minimizing function names...

myWidget = new NewPagePrompt(); is converted to dH = bH(new cH());

You can see the inline call to GWT.log has been removed. However the second call to the log method that wraps GWT.log is still there. eH(fH,'Some Log message for Page number =[' + tG + ']); and is concatenating 3 strings as part of the call statement. The java method private static void log(int level, String s){...} has been replaced by function eH(gH,hH){oG();if(iH >= gH);} Note the call to GWT.log has been removed so the function does nothing.

So the production code still suffers by having the debug messages in there but adding no value, just increasing code size and slowing performance.

So if you are wrapping the GWT class, be careful and check the effect on the generated javascript.

Going forward, the GWT team have some major decisions to make. First Java as a language has changed significantly since 1.4. It’s a lot more complex and getting every further away from Javascript. Keeping GWT current with the latest language spec is a big task, is it worth the effort? Also, there are a lot of requests for more Java-like features to be added to the platform. Some of these e.g. support for Reflection would have major implications on deployed code size.

One feature, I would like is the ability to have non UI java code converted to javascript, and have some way to use it in my non GWT UI apps, where the generated javascript exposes a predictable interface.

GWT 1.4 is out this month, there’s a pre-release already. The feature list looks exciting; a lot of core optimizations and some new UI widgets, in particular the rich text editor is a great addition. It’s taken a while to get GWT 1.4 released, but it looks like it is worth the wait.

GWT is a clever technology and its great to see new approaches being taken in this area. After working with GWT for a couple of months, I can say that while we are still waiting for the perfect AJAX development environment, GWT is a strong contender particularly if your application requires lots of bespoke client side logic with server calls.

11 comments:

aplomb said...

hi,blogger, good article, hoho

TGA said...

Thanks for putting in the time to write this, I found it to be a great overview of where GWT stands at the moment.

Anonymous said...

Forget about Java language versions. Get some of Google's PhD's and miscellaneous whiz kids working on a Groovy-to-JavaScript converter!

Kevin said...

is this the greys anatomy chat room? no? oh. sorry.

Anonymous said...

Is there a table widget equivalent to DisplayTag for use under GWT?

http://displaytag.sourceforge.net/11/tut_basic.html

Anonymous said...

If there was displaytag like table widget, I guess GWT would have picked up immensely.

a Table widget is the heart of modern applications and the demo tables don't look that great.

Vinay said...

I agree. The tables are paged but can't be sorted. Almost all JSF AJAX implementations including RichFaces provide this out of the box. The bean binding is great too.

Bean Binding is lacking in GWT.

Also, creation of WAR file is complicated.

Dhruva Sagar said...

Hi, nice post, I have a question though. I want to know does GWT parse the java file and convert it into html+javascript on the fly or does it first compile the java code and then work with the byte code?
Please email me the answer if possible, thank you.

Adrift said...

How to log to specific file through GWT logging in client side.. can someone answer it?

Anonymous said...

After reading you site, Your site is very useful for me .I bookmarked your site!

Joseph Okharedia said...

Hi, I've used gwt in the past, but I was not feeling it; I was so hyped by jQuery, YUI, JSF, ICEfaces, and Richfaces. I'm back to gwt and I was wondering if its worth reading any books about it. I think you've just convinced me.