JavaOne2006 To GWT or to JSF?
Saturday 20 May 2006 @ 2:15 am
Filed under:

This years JavaOne was filled with JSF, Ajax and even more the combination of the two. On the Pavilion several commmercial vendors were selling their ajax enriched jsf components. The blueprint team showed us the petstore. Oracle showed us how to build custom ajax enabled jsf components. And so on.

In my previous post I noted the Google Web Toolkit hadn’t landed yet completely in my java wasted brain. After four days of conference my brain is still completely wasted with java (two very positive exceptions, I saw the Ruby on Rails framework running on a java VM using JRuby! and I saw some really Groovy things a java programmer can only dream about) but I found some spare time to play with google’s new toy. While the conference only had one presentation about GWT (compare it with all those ajax and jsf sessions) the rumours/facts (find out yourself) on the internet are spreading. And somehow nobody seems to write something really interesting about JSF.

Is there a reason. Yes ofcourse. First it is the hype. GWT is new so GWT should be cool! Second, al the Ajax/JSF things are actually well known already (otherwise it would be impossible to have such a huge coverage on the conference). But between the rumours/facts I could not find out when to use JSF and when to use GWT?

Using GWT you will run into two major drawbacks. The amount of javascript that need to be downloaded will increase (lineair?) with the complexity of the interface. The KitchenSink example application is relative simple but already needs a 100kb of (compiled/generated) code. The other drawback is that your UI is fully (and I really mean fully) decoupled from your server logic. It’s like a Swing or Flash app making RPC calls. And altough very beautiful (designwise) not always as handy and productive as wanted.

GWT also has a lot of advantages. And they are obvious. No more javascript hackery. No more browser problems. All is taken care of by the toolkit. Another major advantage will be the usage of bandwidth after the application has been loaded. It will be minimized to the necessary RPC calls in order to add business functionality to the application. Which at the end will increase user experience. Using this approach state can be managed on the client (and/or in the database). And finally, the support for browser history works wonderful well.

But the biggest advantage is the fact it is a one stop shop. And here the biggest disadvantage of JSF had been mentioned. JSF is just like GWT (and Echo2 and several others) a component oriented approach for building rich web applications but it will allow you to combine several techniques together. It gives you the possibility to mix javascript library x with library y. It’s like combining Swing and SWT on the desktop. Javascript libraries are becoming the assembly languages of the web. And combining assembly languages does not feel right. (By the way, using Tapestry or Wicket this same problem can occur)

So when to use JSF and when to use GWT? I can’t answer this question. When all those beautiful JSF components provided by one and the same component vendor are being used and nothing more (not even self written ones!) JSF still seems a good choice. But if you can accept the drawbacks of GWT, I probably would recommend to at least investigate the possibilities GWT is opening up. (Or take a serious look at Echo2!)

 

— By Okke van 't Verlaat   Comments (14)   PermaLink

Menu


Sha256 mining

Blog Categories

Browse by Date
May 2006
M T W T F S S
1234567
891011121314
15161718192021
22232425262728
293031EC

Upcoming Events

Monthly Archives

Recent Comments

Links


XML Feeds Option


Get Firefox  Powered by WordPress

code validations
Valid RSS 2.0  Valid Atom 0.3
Valid W3C XHTML 1.0  Valid W3C CSS