JSF vs Stripes, which is best? [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 7 years ago.

Which is best, or in other words, whish is easiest to use? Stripes or JSF.

Although I haven't used both in anger I need to gauge what is the best option to work with for both starting new projects and converting existing Struts projects.

I have a fear that JSF won't render as nicely as I want but what are others experiences? Seems Stripes is far more straight forward, would I be correct in this assumption?

Answer 1

I would use JSF. It is used far more widely and iceFaces is a very handy package for JSF based apps.

Answer 2

JSF does not have good press and bad reputation is unfortunatelly justified (one more missed opportunity by the late Sun Microsystems). But, BUT a lot has changed since the question was asked - the new JSF 2.0 version was released.

So what was wrong with JSF 1.X, what made it so iritating when compared to Stripes, Spring MVC or Wicket, Play, Click, etc.?

1. Only POST requests were supported, which caused performance problems (GET requests can be effectively cached), hard to achieve bookmarkable URLs and more
2. JSF 1.X was based on JSP pages, which were not were suited to handle more complicated JSF page lifecycle
3. Creation of components was difficult and cumbersome.
4. Defining of navigation rules was far from flexible and very verbose
5. Mandatory XML configuration
6. No clean resource management method

The good thing is that all this shortcomings were addressed by the new JSF version.

1. GET and POST requests are equally well supported.
2. Configuration can be done with the help of annotations (we can stick to XML where it is better solution), navigation rules definitions are simplified, we can even use convention over configuration approach.
3. Components creation is easy.
4. There are new and very usefull component scopes: view scope and flash scope (similar to that known from Ruby on Rails) that enable users to handle easily more complicated flows.
5. There is standard resource management method and better error handling facility
6. We can define project stages for easier project handling in various environments (testing, production, etc.)
7. XHTML based Facelets replaced JSP as much better view definition alternative
8. Built-in AJAX requests support
9. JSF is a part of Java EE standard, which means they are not going to dissapear overnight if bored developers decide to move to the next shining and more fashionable framework.

And the last, huge JSF 2.X advantage: tones of well designed, great looking and well performing ready to use components (RichFaces, PrimeFaces, ICEFaces). These libraries provide hundreds of of typically used on WWW pages components that are available without writing a single line of JavaScript or CSS. That's huge productivity boost.

Still, JSF might have performance issues as compared to action-based frameworks like Stripes, which work more closely to HTTP requests, without building component model (which is using more memory, more network bandwidth).

But for application which does not have to be extremely performant JSF 2.0 is a very good and rational choice. Learning curve is no longer that steep as is was plus ability to reuse existing components makes it truly appealing. Looking from that point of view Stripes is not so attractive.

So, for instance, for an intranet corporate application used by 2000 employees JSF 2.0 would be great choice.