Wednesday, August 27, 2008

Why GWT matters - part II

Back in May, I wrote about why I thought GWT matters. As promised, I am finally getting around to completing my thoughts on the subject.

In the original post, I talked about how I felt we took a step back when we shifted our development focus more to the web platform and further away from the desktop. We lost some of the richness of the interface for our users and we retreated from advances in programming models in the areas of component and event based programming. It’s only been fairly recently where we finally can have it all (reach/zero deployment with productive programming models).

GWT does provide it all as far as I’m concerned. It has a nice programming model that should feel natural to anyone that has done any desktop based GUI programming in the past. It doesn’t lock you into a particular widget library which makes it a sound investment. It takes care of dealing with the nastiness of writing cross-browser code – because it generates all of this for you.

It makes it easy to write internationalized applications. It makes it easy to provide a working back-button for your users (a rarity for a lot of AJAX applications – hit the back button and you may be taken completely out of the application).

If you really do have to drop-down to JavaScript, there is a mechanism called JSNI which provides this.

However, most of all it is the amount of attention the GWT team has spent on tool support that really gets my vote. The integration with Eclipse makes for a very productive environment.

Of course, there are lots of alternatives in the RIA space. Flash/Flex, Silverlight, and Volta are just a couple of alternatives. Of course, if you are lucky enough to have exceptional JavaScript developers on your team then you may feel comfortable using JavaScript directly (although, I have to say although I like dynamically typed languages, one cannot argue with the ability of statically typed languages to assist you in finding problems earlier in the development cycle - i.e. compile-time vs run-time).

However, GWT seemed to be an ideal fit for my team (no new tools – continue to use Eclipse, no new languages to learn – continue to use Java, and no need to worry about the plethora of browser types and versions).

What are your experiences with GWT or RIA approaches in general? (the good, the bad, the ugly)?

6 comments:

Ido said...

Very good post!
I would just point that the integration with NetBean is far better then the plug-in to eclipse...
It took me 1.5 projects to get to this. But from netbean 6.1 and their new plug-in - it's much better!

Andy said...

Your story it's too sweet. I don't believe. How big is your application

Jason Chambers said...

In response to "andy" regarding the story is too sweet. Of course, there were challenges faced by the team (that's another post for another day).

Here's the kicker, every technology product pretty much sucks when you think about it. Some suck more than others. The job of the architect is to choose the one that sucks the least. There is no one size fits all. What may work for my team, may not necessarily work for you team.

Jason Chambers said...

By the way, these are the ingredients we used for our project:

GWT 1.4.62
Eclipse IDE for Java EE 3.3.2
Cypal Studio for GWT RC4

Andy said...

We use GWT1.5, MyEclipse. I have 300 different pages and 15 developers. JSF after GWT looks so easy and all JSF problems becomes so simple. We are kind of regreting from switching from JSF to GWT. Productivity is decreased and possibility of bugs are increased.

Jason Chambers said...

Andy - that is interesting to hear. I'd like to understand more about your project, the reason you dumped JSF for GWT (it seemed JSF seemed to be working for you - so why switch?).