It was with relish that I embarked on putting the google web toolkit through it's paces. In fact, for the first time in long time, I coded for fun on the weekend. The recent addition of a laptop helped in this regard however...
For a long time I have wanted to build a simple database app to help out a local church. It's a simple app to manage a list of people, their particulars and other properties. Now I thought that would be an ideal test bed for the new google web toolkit - how cool would it be to make it a AJAX rich client app that runs in a browser. A familiar "link" would be all that is required. Because it will run in an intranet environment speed was not a consideration.
All in all, I was able to reach a fairly advanced stage, quite quickly. The API is very simple and easy to use. The "hosted" mode helps a lot. There were a couple of anomalies in the compilation of the javascript - you can't go wild with anonymous inner classes, the parser doesn't handle those very well, and there seems to be some conditions on your package names.
All in all, however, for an application of this nature, the google web toolkit is ideal.
I will have to do some work on the back end to get the data to persist, probably going to use flat files and an xml based serialization mechanism. It's very easy however to use stubs for those back end calls - funny how they're termed back end calls, whereas in actual fact they're simple request to an http server. With AJAX and DHTML the client is no longer dumb!
I had something else that I wanted to throw google web toolkit at (I call it "goowit" for short)...
Recently I built a Sudoku puzzle solver in java - complete with funky swing user interface and all - you enter the numbers, click go and it solves it. I was very keen to see if this would port to java script via gwt so that it can be deployed easily on the net. It took me a while to remove all the non gwt supported stuff - there were a lot of dependencies on java API classes not supported by gwt. I thought at one stage that it in fact would not work. In the end, it did, and I was very impressed.
So it was with great excitement that I finally got rid of all the "cannot import" messages on the hosted mode console - be aware that if an import fails it means that that the class has not been successfully translated, probably because it contains unsupported content. Once this was done, I entered my numbers and clicked go. In an instant it solved the puzzle.
Now for the final test, compile to javascript and see how it runs on the browser. This was where my heart sank, it was unacceptably slow. In fact, it probably would have taken about a day to solve one puzzle! The browser's "A script is taking too long" came up even before the first cell was picked!
Something which ran fine in hosted mode (java compiled mode) was far too slow in javascript mode. Now I'm not 100% sure exactly why - is it because the generated code is inefficient or just because job is too big for an interpreted language. I can't say. I think the rule of thumb here and it sounds obvious is to avoid doing heavy duty, complicated and long running processing with javascript. Not only because it may be slow but also because javascript is a single threaded environment and you need that one thread for keeping the gui snappy. Whilst a javascript process is running, the browser is totally non-responsive.
More exciting discoveries await...
No comments:
Post a Comment