Why go with RichFaces

Lately I have seen a spike in questions such as which JSF 2.0 component library is better? Or RichFaces vs PrimeFaces and there is also performance comparison. It’s probably because JSF 2 is being used more and more and people want to know which library to use. I guess that’s fair. Here is my 2 cents.

It’s important to look beyond just components when comparing these component libraries. It’s safe to assume that most have very similar components at this point.

RichFaces 4 is more than just a component library, it’s a rich framework for JSF providing:

  • Over 100 rich and Ajax components
  • Skins
  • Client-side validation (extension to Bean Validation)
  • CDK (Component Development Kit)

RichFaces 4 is JSF 2 based with a CR (Candidate Release) version out very soon. From there, we are just a few weeks from the final version. I know version 4 took a little longer than everyone expected but this version is more than just a typical update. It’s a significant upgrade that includes the following:

  • All JavaScript is now based on jQuery
  • All component were reviewed for consistency, usability, and redesign following semantic HTML principles
  • Both server-side and client-side performance optimization
  • Strict code clean-up and review
  • New and easier to use CDK (Component Development Kit)

I think it’s well worth the extra wait.

Other component libraries usually just wrap existing JavaScript widgets from Yahoo UI (YUI) or similar as JSF components. RichFaces approach is different. RichFaces uses jQuery as the foundation but most component JavaScript functionality is being developed by RichFaces team. Yes, it’s takes longer but also gives more flexibility and customization options and doesn’t lock components into the underlying JavaScript library.

Installing RichFaces 4 has been simplified as well. Just drop the Jars into your project, nothing to register in web.xml file anymore.

If you look at Ajax features in JSF 2, then you can see it was greatly inspired by the RicihFaces a4j:support tag. Plus, many components have Ajax built in as well.

The RichFaces community is very active and always willing to help. And don’t forget that RichFaces is backed by JBoss and Exadel.

RichFaces might not have the shiniest components. It wasn’t the first with JSF 2 support. (This argument will be mute in about 1 months). But, keep in mind that RichFaces is used in thousands of projects and has been proven in small, large, and enterprise projects throughout the years. And that’s, probably one of the most important things to keep in mind.

Published by

15 responses to “Why go with RichFaces”

  1. […] This post was mentioned on Twitter by RichFaces, Max Katz, Matthias Wessendorf, Jay Balunas, Julio Cesar Silveira and others. Julio Cesar Silveira said: RT @richfaces: Right on Max!! RT @maxkatz: Why go with RichFaces http://ow.ly/3RXX3 […]

  2. The design for the time of day setter on the calendar component should be revisited. Making a second click to engage the time interface is an awkward interface and slows down high speed input necessary with call center and data entry workers. The current time interface is also quite small so it takes some focus to target and click the arrows with the mouse.

    A simple chevron delimited breadcrumb component would be great too.

  3. Max,

    thanks for the update of the current state, and for the huge amount of work you all put into RichFaces.

    One thing that reads strange in your post:

    You say:
    “Other component libraries usually just wrap existing JavaScript widgets from Yahoo UI (YUI) or similar as JSF components.” (-> other frameworks are not so cool, because they just wrap around existing js-frameworks)

    and

    “It’s a significant upgrade that includes the following: All JavaScript is now based on jQuery” (-> RichFaces is cool, because it wraps around jQuery)

    To me that sounds like a contradiction, or doesn’t it?

    As a long-term RichFaces user I found myself switching to PrimeFaces simply because it was the only JSF2 component framework available. I can’t stress enough that it’s a pity that it took (takes) such a long time for JBoss to come up with a JSF2 solution. I reckon that it’s way easier to loose ground against competitors than to win it back… 😉

    cheers,
    Jan

  4. Most of PrimeFaces components does not work properly on GAE. GAE demo don’t change for a half an year. GAE has especial problems and just follow JSF 2.0 is not enough. I had to switch to RichFaces 4 because they test all components for GAE, despite the fact that PrimeFaces looks better for a first glance. They don’t have static resources, mojarra is practically not functional. Little success is possible only with MyFaces, because they support JSF more precisely. I spent a lot of time in forum trying to use PrimeFaces. PrimeFaces is great, but to tell the truth he doesn’t test it against GAE.

  5. @Walter: thank you for your feedback. Did you can try using enableManualInput=true – that will allow you to enter the date/time into an input field directly. As for breadcrumb, right now it’s available as part of Seam.

  6. @Jan: RichFaces 3 uses jQuery and Prototype. RichFaces 4, to make everything more consistent and easier to work with, is now only based only jQuery.

    As the foundation and the core, we do use jQuery. We didn’t want create what’s already available. But, most rich components JavaScript functionality is being created by RichFaces developers. Hope this makes sense.

  7. I have to second the remark below. The time interface on the calendar component is awkward, to put it mildly.

    There are a number of jQuery plugins that handle date/time values in a much more user-friendly manner. I hope the RichFaces developers take a look at some of those, and find a way to improve the calandar component so to make it simple, easy and obvious to enter a time with a date.

    The design for the time of day setter on the calendar component should be revisited. Making a second click to engage the time interface is an awkward interface and slows down high speed input necessary with call center and data entry workers. The current time interface is also quite small so it takes some focus to target and click the arrows with the mouse.

  8. @Mark @Walter: I’d post this feedback on RichFaces forum or Jira for everyone to see, the RichFaces team and the community.

  9. […] Katz makes the case for the RichFaces 4 component framework. This entry was posted in Ephemera and tagged JSF, […]

  10. Dear All,

    what do you think about using Richfaces for running a very high volume online shop that sells to end customers over the web?

    What would be potential advantages / drawbacks?

    Thanks for any hints …

  11. @T. Hei_nz: why not? if everything is designed correctly..

  12. why jsf . best use jquery at client spring 3 or struts 2 mvc

  13. […] comparações que o pessoal no mercado fez, inclusive destacando alguns pontos de desempenho, para ajudar em suas […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.