views:

2398

answers:

8

I'm currently working on a web app that makes heavy use of JSF and IceFaces. We've had some discussions of moving to another presentation layer, and I thought I'd take the discussion out into SO and see what the experts think.

I'm curious if anyone could weigh in on the pros and cons of the various Java presentation layer technologies. If you've only worked with one, say why you love it or hate it. If you've worked with several, give your impressions of how they stack up against each other.

Our technologies under consideration are:

  • IceFaces
  • JSF (without IceFaces)
  • GWT (Google Web Toolkit)
  • Wicket
  • Tapestry

And if I'm missing anything from my list, let me know.

Thanks!

+3  A: 

I've used GWT for a couple small projects. Here are some things I like about it:

  1. It's ajax by default, so I didn't have to make it do ajax, it just came along with using GWT.
  2. It's got good separation of client versus server-side code.
  3. I can unit-test my client code using junit
  4. It lets you built crisp, snappy apps, largely because it's ajax.

Things I don't like:

  1. Some things don't work as expected. For example, I've seen cases where click events didn't fire as expected, so I had to do a workaround.
  2. Auto-deploy to tomcat running in eclipse sometimes just stops working, and I could never figure out why.
Don Branson
+2  A: 

The biggest question I'd ask is why are you changing presentation layer? That's a very expensive cost and I can see the benefits of one technology outweighing the others by as much as the cost to change...

Stephane Grenier
Good question. Our dissatisfaction with IceFaces stems from a) mystery-meat exceptions from hell -- a problem endemic to the JSF lifecycle, b) it's perceived by many here as heavy and slow, and c) poor community support. We're considering the change for a new project, not our existing app.
rtperson
It's good if it's for a new project. I'm also curious about your reaction to IceFaces since I've considered it before as well. When it first became open source a while back it seemed like a very interesting solution. But I've never tried it on a full scale app... Very interesting.
Stephane Grenier
The big pro with IceFaces is that it makes it very easy to build an AJAX-enabled interface. It does this by hiding a lot of complexity. But, of course, there are times you want to look under the hood, and IceFaces makes this more difficult than it needs to be. (continued...)
rtperson
For example, if you set an ID on a DIV, IceFaces' rendering stage litters the IDs of every single component under that DIV with the name you just added. We have a few small Javascript effects on our site, all of which break on a routine basis because of this. Also, it doesn't play well with JQuery.
rtperson
Interesting... And what about performance? I was always curious on a larger site with more traffic.
Stephane Grenier
Our current IceFaces project has no more than a few hundred users, so I really don't know much about its performance under heavy loads. Having worked on a few large e-commerce sites, I have my doubts about how well IceFaces would scale up to that kind of traffic. But I honestly can't say for sure.
rtperson
I found some good info on IceFaces scalability here: http://www.icefaces.org/JForum/posts/list/2840.page. Bottom line: for large, scalable sites, AJAX push can be tough to work around.
rtperson
That's what I was wondering. On a larger site, you don't want everything to be ajax'ed, you want to pick and choose which elements are important. Thanks for the tip on IceFaces, it's great to hear from someone who's used it firsthand. Thank you.
Stephane Grenier
A: 

I'd wonder if you a have a service layer that's distinct from the web client, something that the web controllers simply invoke to get their work done.

If you do, the choice of web UI technology can be decoupled from the back end. If it's exposed as a contract first web service, you can have different apps share it. As long as your clients can send and receive XML they can interact with your services. Want to switch to Flex? No worries - point it at the service and render the XML response.

duffymo
That's a good idea. Our layers are largely decoupled, though not quite SOA-strength. And, while we do use web services here, performance between our presentation and service layers is enough of an issue that we probably won't go that direction this time around.
rtperson
+1  A: 

In short:

= JSF =

PROS:

  • component architecture;
  • many libraries & tools;
  • somewhat good IDE support

CONS:

  • heavy weight, both in CPU/memory and learning curve;
  • when something doesn't work as expected, it's difficult to debug

= WICKET =

PROS:

  • lightweight;
  • sensible templating system;
  • good tutorials;

CONS:

  • reference documentation is not so well organized and deep as are the tutorials;
  • development team had some serious difficulties, especially when becoming and incubated project. This lead to confusion on important aspects of the framework, at that time I had to switch to another framework because of this...
Megadix
+3  A: 

My opinions are quite heavily biased towards Wicket because I've been using it for a while after tripping over JSP mines far too many times.

Wicket PROs:

  • True separation of layout and code.
  • Component based which means high reusability of site elements; For example you can create prettified form with automatic labeling and CSS styles and everything and just by changing it's DAO object in the component's constructor it's completely reusable in another project.
  • Excellent support for things like Ajax, Portlets and various frameworks in general directly out-of-the-box AND more importantly it doesn't rely on anything else than slf4j/log4j to work, everything's optional!

Wicket CONs:

  • Development has some confusion about things in general and Wicket generics are a bit of a mess right now although they've been cleaned a lot in 1.4
  • Some components (like Form.onSubmit()) require extensive subclassing or anonymous method overriding for injecting behaviour easily. This is partly due to Wicket's powerful event-based design but unfortunately it also means it's easy to make a code mess with Wicket.

Random CONs: (that is, I haven't used but these are my opionions and/or things I've heard)

  • GWT is JavaScript based which sounds stupid to me. Main issue is that it reminds me too much of JSP:s and its autogenerated classes which are horrible.
  • Tapestry doesn't separate markup and code properly in a manner which could be easily validated between the two which will cause problems in the future.
Esko
Esko, I share your distaste for JavaScript, but you might want to take a look at Douglas Crockford's "JavaScript: The Good Parts." Also, working with JQuery has done a lot to stifle my gag reflex when JavaScript is mentioned.
rtperson
Thanks, I just wrote the name of the book to a post-it so I'll check it out, eventually. Oh and Wicket of course has great support for jQuery, mootools, dojo and scriptaculous through Wicket Stuff (component incubator subproject).
Esko
Tapestry 5 let's you separate markup and code, but does not enforce it like Wicket.
Sergey
That's true, however Wicket's strong part is actually enforcing it, it doesn't let the devs be lazy in that regard where the devs really shouldn't be allowed to be lazy.
Esko
+1  A: 

What about Stripes?

A_M
+2  A: 

My pick would be Wicket. Have used it and is gives excellent re-usability. It has one of the most vibrant forum/mailing list. As a question and its gonna be answered in minutes. It has excellent support for AJAX. One of the usual cons attributed to Wicket is the steep learning curve. Well those were one of the old age cons which hold no value anymore now.

JSF: Better stay away from it. Another team which developed a project on JSF is now thinking to shift to Wicket after our success with it.

@Megadix: Like you said the documentation was poor in the beginning, but not any more. There is an excellent book called Wicket in Action written by the developers of Wicket. The sample code provided on the site is also a good place to start and learn

Franklin
A: 

See my comparison of Wicket and Tapestry 5: Difference between Apache Tapestry and Apache Wicket.

Sergey