Usage of JSF vs other web frameworks

Question

We are in the process of re-evaluating our usage of JSF (brought in before I came onto the project) vs the possible usage of other web frameworks such as Spring MVC.

From my view point, it appears that the development time to building out pages takes a very long time using JSF (never developed with) compared to using Spring MVC (which I am familiar with).

I understand that JSF is a "Component" based framework with the ideal of building or making use of reusable components. But so far, that has not been the case. Most, if not all of our pages require new components. I am getting estimates of weeks for the development of pages which I feel could be done in days using an "Action" based framework.

Wondering if I am off base here or maybe the team in place is not the correct team or has the correct skill set for working with JSF.

We also run into issue with our Analytic tool, users bookmarking pages and blowing out the application server heap - getting Out of Memory Exceptions a lot.

We are building out a E-Commerce/Auction site running on WebSphere 6.1. We use Spring and Hibernate.

Answer 1

I too am a big fan of Spring MVC--particularly when used in conjunction with Spring Webflow, which is just awesome. Now Webflow can be used with other Web frameworks but it's most natural fit is with Spring MVC.

In my case I went from Struts (1) to Spring MVC. We had a lot of built up infrastructure for using Struts. One thing I underestimated when writing new pages in Spring MVC is how much time we would spend essentially reinventing that infrastructure. I'm talking validation, common logic and so on.

Now I don't know a whole lot about JSF. It sounds like you're having that problem (as you would with any Web framework). The fact that that process is still going on may be a real problem. You can't ignore the fact that you'll have it with something else too.

I find Spring MVC and Webflow are best once you have some infrastructure around validations and forms logic. For example, we had this process a lot on our system:

1. User places order;
2. Server validates parameters and either rejects order (return to (1)) or accepts it;
3. The verified order is returned to displayed to the user who confirms that they either want to place the order or cancel it;
4. If they cancel it, display a page saying it has been cancelled;
5. If they approve it, verify the order again;
6. If it fails validation return to (1);
7. Otherwise place the order and display the result to the user.

It may sound convoluted but it came up a lot. Where Spring MVC really shines is for this kind of scenario you can create a custom controller and then the actual implementation just becomes an issue of plugging in the right views and support beans.

Don't underestimate the cost of developing and testing required infrastructure.

The other thing to consider is team experience: if noone else has Spring MVC experience then that's going to present some issues.

So be very careful taht you don't change just because it'll make you personally more comfortable.

Answer 2

Cons of JSF we found:

• The "standard" 5-phase path is very simplistic and inflexible.
• Varying from the normal method is complex and non-intuitive
• You simply can't use JSF without Facelets and Rich/ICEFaces.. at the LEAST, other modifications/addons are helpful (SEAM, etc.)
• It's ok to encapsulate functionality to make things "simpler"... It's NOT ok to make it next to impossible to muck about in there when circumstances require it.
• server-side storage of component tree is incredibly inconvenient when trying to design a client-side-reactive page.

We've moved to Groovy/Grails here. The "default" convention is easy to understand and easy to bypass when necessary. Conventions also apply to modifying the framework (no multi-xml/code file changes). I have yet to need to modify an XML file by hand at all. It's just easier to work with, and is flexible enough for what we need.

Grails incorporates Spring WebFlow and Hibernate, only you don't have to modify XML; Grails coding conventions are converted during compile/run time.