- Java Server Faces 1.2 are already shipped with every Java EE 5 server - so before you are choosing a more esotheric framework, you should at least evaluate JSF.
- JSF are component based - the development model is event-driven and similar to Swing
- A backend object (backing bean) receives the events (just a method)
- Bi-directional, declarative Data Binding can be used to synchronize the view-components with the backing bean
- The backing bean runs on the server - it can access e.g. the EJB 3.0 per Reference. "Fat Client" programming model is possible :-). This is a huge advantage. No value objects, client objects etc. are required.
- Model View Presenter / Model View Controller patterns are easy to implement. The presenters / controllers can be even shared with Swing apps (in theory - in practice the views are too different).
- Convenient data conversion for the common types (e.g. from String to int) already happens behind the scenes.
- Validation support is already built in.
- Navigation / Page Flow are provided and standardized.
- Visual tool support for JSF is outstanding. Most of the tools are free e.g. Netbeans 6.1, Oracle JDeveloper, Eclipse with Plugins (e.g. Visual Page Designer in WTP 2.0). Some tools (e.g. Netbeans) provide visual support for page flows.
- There are already many JSF component providers - many have AJAX support, and are opensource.
JSF programming with good tool support can be very productive (in my opinion - unbeatable). So it is absolutely possible to build from scratch a CRUD app in three minutes (with nice table - sorting included) - without hacking. In case a given JSF provider fully covers your customer's requirements - it's the best choice. Some extensions like Shale or Tiles, help you better structuring your application / page flow. However I would only use them if necessary (every jar increases the complexity...- and makes the deployment harder).
Nevertheless JSF 1.2 has also a "dark side":
- The amount of XML-configuration is considerable (therefore tools are absolutely needed - vi, even emacs are not enough :-))
- Building custom components requires some deeper knowledge - it is not so simple, as it could be.
- Every request is a POST request - you will need some workarounds for bookmarking etc.
- For more sophisticated applications - you will need to understand the "6 phases" - this can take a day of experimentation to fully understand it.
- Customizing the look and feel of the visual components, can be time-consuming. Go with the default if possible.
- The whole component tree is cached on the server in memory - you should plan some performance tests to verify the requirements. In general the performance is o.k.