Which framework should I choose - Seam, Wicket, JSF or GWT?

Question

I'm debating whether to use Seam, Wicket, JSF or GWT as the foundation for my presentation layer in a Java project.

I narrowed my selection of Java web frameworks down to this subset based on job market considerations, newness of the technology and recommendations from other S.O. users.

What factors should I take into consideration in deciding among these?

Answer 1

The only one of those I've used is JSF, so I won't be able to give you feedback on the others, but here's my take on JSF. In my experience, the minute we converted from JSF in JSP to JSF in facelets, life got MUCH easier, so I'll focus around facelets. Also, It looks like Seam and JSF are not mutually exclusive.

Pros:

• Creating facelets xhtml components is simple, which promotes re-use.
• Decent templating abilities using built in tags like ui:insert, ui:include, and ui:decorate
• Simple access to Spring beans through faces-config
• XHTML based so web developers unfamiliar with java can still be effective
• Good widget library available in tomahawk/trinidad

Cons:

• Post requests only. This can make bookmarking difficult.
• Not as built-in ajax-y as GWT, but this may be fixed if used with Seam

I'm by no means an expert in JSF/Facelets, so I'm sure there are others I've missed. Hopefully someone else will also elaborate.

Update for JSF 2.0:

• Has even better re-use capabilities with composite components
• Widget libraries for 2.0 include primefaces and mojarra scales
• Allows get requests and bookmarking
• Has built in Ajax support
• See http://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/ for more on JSF 2

Answer 2

Seam is an application framework, not really a presentation layer. It was originally developed to make JSF less painful, but has evolved into a more general purpose dependency injection framework.

I believe that you can use Seam with JSF, Wicket and GWT. JSF support is primary and excellent; I'm not sure how well the other two are supported.

Since the focus of your criteria seem to be the marketability of your skills, I would suggest trying out Seam and JSF via Facelets. JSF is a well accepted standard and is actually enjoyable to use if you are using Facelets. You can have slick AJAX functionality via Richfaces and Ajax4jsf. Seam is being more or less standardized via the JCP.

Answer 3

In a long term scenario I'd recommend using technologies backed by a Sun specification. This has so far proven to give multiple implementations resulting in choice (frequently also open source implementations), plus behaviour tends to be very well defined.

That will help you in a maintainance scenario, which - hopefully - your code will end up too in time. Well-written code lives forever :)

In this particular scenario I would suggest JSF. I have only tried the Apache implementation of 1.1, but it hurt to be on top of JSP. We are to revise it soon - I expect to look into having JSF on facelets.

Answer 4

I've used Wicket and GWT pretty heavily. Never really learned to love Wicket.

My ego blogged about it http://salk31.blogspot.com/2009/07/wicket-ajax.html

Looking at GWT 2.0 uiBinder today reminded me how annoying it was in Wicket to have to match the XML component tree with the one created in Java. The GWT spin on this looks vastly better to me.

I've not used Wicket for over a year so maybe they have fixed a lot of this but given modern browser and JS support I can't see the point of doing all this on the server (I know, I know data locality).

Answer 5

Both Wicket and JSF are obsolete by HybridJava v0.98: http://www.hybridserverpages.com/

Answer 6

JSF is deprecated (JSF is not even listed as a framework to compare when evangelists compare or talk about web frameworks in 2010).

Now full fledge large scale applications are created using GWT, YUI, JQuery etc.

Read some articles over google and above will be obvious.

(ALL JOBS on JSF are to support legacy applications).

Answer 7

If you consider only job market , you should choose JSF. But, I belive that the future of RIA belongs to GWT and gwt like client side technologies.

I think that the most obvious upside of GWT, it is better scaleable than server side presentation layer technologies such as JSF, wicket. Because , server does not need to store client state and the client cpu power also are also used.. It is a huge benefit, you dont need to serialize client state between server computers to achive fault tolerant system.

Answer 8

I vote for JSF I created this blog about my experience with GWT(about 1 year on that I spend at work). Occasionally , I also wrote JSF application(about 1 year on that I spent at home)

My mistake was I chose simple MYFACES (simple and old JSF implementation).

But even that one is better, than GWT , because it's easier to write. Easier to understand and 10 other reasons(see blog link below)

The best solution if you need just presentation layer is GOOD JSF implementation, like Trinidad, like RichFaces.

But if you need complete 3 layers solution(presentation, business, data) - take JbossSeam.

I have no relation to Jboss, I just read, tried and know!!!!

Google's products are highly OVERESTIMATED. You CAN build good application on GWT, but it will have 10 disadvantages(see blog).

I write GWT RIGHT NOW, making breaks to tell the truth here...

It's not good. Trust me. Or not trust me, just go in that way. It's your problem, buddyyy.

http://javafuck.wordpress.com/2010/07/28/gwt-is-abbreviation-for-greedy-and-wasteful-technology/

Answer 9

Thanks wicket guys for remaining sober and keeping over this discussion. I am a wicket user and i love it. My main reasons are :

1. Its a component framework. I love working with components as opposed to full pages.

2. I can let the designers work on the templates and pages as i work on the java parts

3. There is nothing new to learn. Its "just java and just HTML"

4. I like its ajax Fallback mechanism. Where there is not javascript support on a browser especially on mobile devices, it falls back to plain html and everything works.
5. Its lack of xml configuration is a plus
6. It supports everything i would want in a web application. e.g validation, internationalization, back button support and restful URLs among others

My previous experience is GWT and JSF 1.0

regards. Josh

Answer 10

My last comparison JSF-GWT-FLEX

Answer 11

I've used GWT since version 1.4 and JSF since the 2.0 spec came out.

GWT is a client-side framework, it generates JavaScript from Java. Your architecture would be a pure client-server, which means:

• Best to use coarse-grained services
• All objects that travel to the client side should be fully serializable (it means there's no lazy load, or OpenSessionInView pattern)
• Since GWT 2.0 you can design your gui using xhtml, which is much easier in regards to styling & structuring HTML
• GWT tends to favour good architecture, if you mess it up it will be bad to refactor
• Perfect History (browser back button, bookmarkable urls) support is hard, you probably have to roll your own, although it's easy to hack something right up front

JSF is a component-based framework, with a view-first design (code-behind if you like):

• It's easier to do some type of webapps (stateful, like shopping cart)
• JSF+Seam have suport for conversations (think wizard-like pages that maintain state across several pages)
• You can implement OpenSessionInView, depending on your stack. It's probably not recommended if you use EJB for service/business layer
• JSF2 has superb support for AJAX, and with a component suite like RichFaces you can build nice webapps
  • But if you want exquisite javascript behaviour, you'll have to write some javascript
• JSF tracks the current UI state in client or server-side. This is a tradeoff between network traffic or server memory.

Resume:

• GWT is more adequate for web applications (think gmail) that require the best client-side performance. It's easy to write custom components (you write Java) and since your server-side is just a service layer you can be fully stateless on the server side.
• JSF is more adequate for mostly CRUD applications that are better suited for component-oriented stuff: think a hotel/flight reservation system, an online store with a shopping cart, etc