JSF 2.0 vs. Wicket vs. SpringMVC 3.x for special requirements

Question

Searching for a web framework practicable for my few critical requirements in a new Java EE 6 project, I read here the now many threads on this topic, and I finally could reduce the number of envisioned frameworks to JSF 2.0, Wicket 1.4 (among the component-based) and SpringMVC 3 (among the actions-based).

Concerning these frameworks, I'll need some advice if and maybe how the following requirements are realizable:

1. Preferably separated designer/coder workflow, so that designers -- optimally -- can independly elaborate their HTML, CSS, JS/jQuery files with their favored tools like Dreamweaver.

2. Easy integration of the many existing (fancy and animated) jQuery components, such as this Sliding Login Panel (a demo can be seen here). Thus, the requirement actually is easy integration of exiting HTML+CSS+jQuery code AND ALSO:

3. For an ui component tree, a sync mechanism to synchronize the view state dynamically changed on the client side (via JS/jQuery) with the corresponding view state on the server.

   I guess I'll need that. E.g., think of the above "Sliding Login Panel" having an 'open' or 'closed' changeable on the client side via JS. Its initial state is programmed to be 'closed', and the user decides client-side to always maintain it open. Now, when the user navigates somewhere and comes back to this view again, the login panel state is unintented 'closed' instead of 'opened' (as this is its initial state and no dynamic state updates occurred server side).

   Thus, a sync mechanism will be needed, right???

4. Optimally externalized (somewhere centralized) navigation rules for
   (a) arbitrary inter-page navigation (static nav rules), and
   (b) "wizard-like" navigation (dynamic nav rules dynamically determined from current state/outcome).

5. A good performance (load time, server memory comsumption, experienced responsiveness, etc.).
   
   

The obvious questions are:

1. Which of these reqs are (well) supported by JSF2, Wicket and Spring MVC3 and which not?

2. Generally, with this reqs -- and as I'm still unsure with the technical aspects/consequences: Which framework type (component- vs. action-based) should be chosen in that case (i.e., which critical decision aspects or "rules of thumb" should be kept in mind)?

Thank you very much for your advice and help.
Martin

Answer 1

JSF:

1. In the template language of JSF (Facelets) this is easy. You just write regular HTML and only add the jsfc attribute for the dynamic parts. See the wikipedia article for a quick example: http://en.wikipedia.org/wiki/Facelets
2. Using JSF's composite components this is really easy. Just put your jquery stuff in an .xhtml file, add a small header and it's reusable as a component everywhere. Many jquery based components are also directly available using PrimeFaces
3. JSF excels in this sync mechanism. Synching happens via a well defined and easy to grasp number of steps. Basically, this sync mechanism is more or less the prime reason for using JSF instead of directly writing jquery.
4. JSF has exactly this and it's even called exactly that navigation rules. They are a powerful mechanism to define navigation in an external .xml file. A navigation rule can be defined based on logical outcomes and/or actions taking place on specific pages. They can be forward or redirect based, with or without extra parameters.
5. JSF overal performs really well. It keeps (saves) state, so this costs you some memory, but it's smart enough to only partially save this (values differing from their original values). You can furthermore decide to store this state on the client or the server. Because of the very convenient view scope, small amounts of data used by your backing logic can very easily be cached between requests. This saves you from hitting the DB after every request and can greatly improve performance.

One of the areas where JSF really shines is its component model. It's very easy to compose components yourself via its composite component concept. You can also create components in Java, which is a bit more involved but still absolutely not difficult.

Because JSF's component model is standardized and very clearly documented, many, many third parties provide ready to use component libraries. E.g. RichFaces, Primefaces, OpenFaces, IceFaces, Trinidad... the list is nearly endless.

Some extra note about the performance. In comparing any of three web frameworks you mention the difference is negligible, and as a rule of thumb the web framework is not where the majority of time is spend when processing a request. This is almost always in the Database and in IO.

The web framework can help by making it easy to prevent going to the DB, but even if web framework A is 10x faster in synthetic tests that only hit the web layer than framework B, then in practice you would barely notice this if only 5% of a request's time is spend in that framework.