Google Web Toolkit… a first look

When I was first exposed to the AJAX technology and how it works at the Sun Tech Days, I thought to myself, why then can't you code in java and get a tool which allows you to "press button for thick client", or "press button for thin client". It would have to be some kind of a cut down version of java because you wouldn't be able to do everything on a thin client than you can do on a thick client.

In a nutshell, this is what Google has done with their google toolkit. It is, like a friend first said to me, "a way to write AJAX applications with standard java code".

They have solved a lot of the problems and what they've come up with is something far more amazing than I was thinking at the Sun Tech Days. especially since, having seen google's solution, the number of issues that I was just plain not aware of are vast.

Let me mention however, that they have not solved the "deploy to thick client" - though in a sense their "hosted" mode is exactly that. I think because that need is in fact not required in any case. There are already API's available for building thick client gui's and besides, practically speaking thick and thin clients are so different that you would not be able to seemlessly deploy to whichever you choose.

Google's Web Toolkit - Summary of usage…

• They have built their own set of gui controls - the functionality of which can be realised in html. If you start using them, and you are familiar with html you will soon see this. They are "wrappers" onto the features of the html controls. They also have some of the familiar layout managers - DockLayout (BorderLayout), FlowLayout, TableLayout and others.
• They "translate" java code into javascript code. This, to be honest, is probably the biggest achievement of the google web toolkit. It is not therefore an AJAX toolkit as such. It is far more than an AJAX toolkit. This feature by itself is amazing. I have a sudoku puzzle solver that I built with a swing gui. I am very keen to see if it will translate into javascript so I can run it on the client (no AJAX). There are some limitations to what can be done, since java is not javascript. They also have a little bit more work to do on the parsing side - if you find that your code is not translating properly then you need to adjust the source code a little (it parses the java source code). The prospect of porting my sudoku solver to javascript by hand is not something I would dream of doing, this way I can see it in javascript, painlessly.
• Handle AJAX calls with standard RPC infrastructure but with additions to make it asynchronous. For someone who's done RPC in any context, a lot of the concepts involved will be familiar.
1. Build the remote interface, build the remote implementation of the interface
2. Build the Asynchronous remote interface - contains every method in the synchronous interface but with call back reference added to each call.
3. The process of calling is…
1. Instantiate the remote interface (on the client).
2. Specify the location of the "server" - in this case it is a servlet which you call.
3. Make the call - when making the call provide an implementation of the AsyncCallBack interface. AJAX familiar people will recognise this concept.

It didn't take me long to write a simple web application in google web toolkit which takes two numbers as input and multiplies them or adds them according to the button that is pushed. When I get a site I can place this kind of content on (zip files) I will put it there so that people can acquire it. For now, if you're interested, email me and I'll pass it on.

I'm using eclipse and created two run configurations for GWT compile and GWT run. When they mean compile however, what is interesting is that they're converting the java code into javascript code. Going from one language to another! Believe me, making sense of the compiled stuff is impossible - they've obfuscated it quite a lot and rightly so.

The payload can be fairly big - a fairly simple app I'm busy with comes to 82K. It might sound like a lot, but when you consider that there is absolutely no library code on the platform on which it is running it puts it into perspective. There is no big JVM required, the client only needs a browser.

All in all, it is an amazing tool. I'm not sure if it is ready to write business applications on - but I do think that day will come.