Tech Ravings

So the below post says I was going to introduce Google Web Toolkit. Well that was five weeks ago and the upcoming release of an application has meant working from around 3:00 a.m. to 7:00 p.m. and all seven days a week. There still are seven days in a week right?!? A major part of this time actually had to deal with a very complicated widget that was being done in GWT.

I completely understand Googles intention of creating GWT because there are not many JavaScript programmers that understand anything other than form validation. You would natrually assume, or maybe it was just me, that the GWT would also help with the HTML and CSS as well. That isn’t the case however, so I’m back wheeling on what I said about posting about how to use GWT.

Here’s why I found it so utterly useless from many aspects, even for simple widgets.

I’ll take the first approach from Java, it’s a language I haven’t used a lot so I had to really burn the candles at both ends to remember how to work with Java Swing. With the exception of adding one third party library to which I had to manually include in the GWT classpath config little did I know that GWT doesn’t even include all their files. Had it not been for the third party library I would have never known how to include the GWT defaults.

The application of swing really wasn’t any different of what you would expect when working with panels and components, what was different was how to edit the properties. Properties like the background color, widths, heights, etc. Approximately 90% I was using the DOM object to get the target nodes element and then apply the styles. I also found many occurances where I had an node but had to cast into an element just to apply styles. Only a few panels and limited components would accept Listeners. This was a major pain considering that if the application was done in JavaScript I would have access to a full array to use on every element that was created. So panels upon panels were needed just to do simple DHTML. All these panels created a muck with the resulting HMTL.

It’s probably appearant right now that from a javaScript programmers point of view I was not feely good about GWT. The bloated HTML, lack of event Listeners on those things that I needed to have them one. so and so forth. The end result? Well it worked but the performance in the hosted mode was really really poor although slightly faster in web mode. However I will state that application had some pretty heavy calculations to do as well as parse a 7000 datapoint XML files.

Even these two things didn’t make me quite as upset until it was time to test in web mode. The suggested method to build an application is to test in hosted mode until ready to release then view in web mode. So after spending all this building my application and making the colors right, text fit, etc I opened it up to the browser. I was shocked as nothing looked right. You see all that time built stylizing in hosted mode using the setStyle methods only really worked in hosted mode. I thought the interpreter was supposed to do this for me. Wrong, apparently I have to build the CSS for the web mode along with the hosted mode. So if you’re a java programmer who doesn’t know CSS you’re going to be upset.

The last atrocity GWT did for me was to create about 18 different files for this one app. There were several different .js for “browser compatibility”, XML description files, and a few others that had to be placed on the server. It would be to complicated a filing system to have many GWT widgets.

So no I’m not going to proliferate GWT as a technology and Google can stay out of my DOM.

I’ve always liked working with widgets as they can be quick and easy or both challenging and fun. I’ve built widgets in many scripting languages as well: HTML; JavaScript; PHP plug-ins for WordPress. I’ve also built widgets using the Yahoo widget frame work  but to keep an open mind I decided to look into Google Web Toolkit (GWT) frame work as well. This article and subsequent related articles describe my limited-java experience while learning and using GWT.

The Google Web Toolkit as described by Google is a Java development frame work that allows you to develop widgets in Java which is then compiled into JavaScript. GWT supports the HTTPRequest object, XML Document, and even Remote Procedure Calls. GWT is touted as being cross browser compatible without the need to detect.

Google Web Toolkit can be used with any editor but Eclipse is recommended. When creating a GWT widget application there are arguments to signify to build the Eclipse project file for direct import into Eclipse which is quite handy. Although you can certainly test your app in both hosted and web mode from the Command Line Interface you can also use Eclipse to test both modes as well, again another handy feature.

So why would I, having many years of deeply working with JavaScript, use GWT? My Java experience is limited and this would be a great way for me to get back into it. Certainly I’m not saying that GWT is Java and as a matter of fact you can only use a limited amount of true Java and below version 5.0. The GWT classes are however Java so there is the trade off.

The other neat feature is the junit testing which I have not gotten into yet. Of course I unit test my JavaScript using jsUnit but even that can be tricky and really sticky when doing HTTPRequest tests. Not to mention the JavaScript test are nothing more than bloatware when moving the js files to production. Keeping in mind that I use JavaScript classes and not free functions so my unit tests must be internal to the object.

No more alert(); type debugs either. Using System.out.println() within Eclipse you can see the output within the console. I haven’t gotten to the point of using the debugger yet. Should be interesting.