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.