I have heard a lot of good about JSF but as far as I know people also had lots o
ID: 650548 • Letter: I
Question
I have heard a lot of good about JSF but as far as I know people also had lots of serious complains with this technology in the past, not aware of how much the situation has improved. We are considering JSF as a probable technology for a social network project. But we are not aware of the performance scores of JSF neither we could really come across any existing high performance website that had been using JSF. People complain about its performance scalability issues.
We are still not very sure if we are doing the right thing by choosing jsf, and thus would like to hear from you all about this and take your inputs into consideration.
Is it possible to configure JSF to satisfy the high performance needs of social networking service ? Also till what extent is it possible to survive with the current problems in JSF. What exactly are its problems ?
I am not worried about the development complexities with JSF what others usually complain about because as per my personal experience I believe that's not at all true, but I am more concerned about what performance and scalability issues. And please don't just abuse it on its old issues linked to previous versions. I just care about the present state whatever had been its past.
Explanation / Answer
JSF is most definitely capable of delivering high performance web applications. The app I'm currently working on is completely in JSF and from the log stats I can see that many non-DB intensive pages have minimum execution times of 0ms and average times of less than 10ms.
Some of the Wicket guys have been saying things about JSF' performance, but according to this elaborate benchmark JSF actually performs better than Wicket: http://prezi.com/dr3on1qcajzw/www-world-wide-wait-devoxx-edition/
Notice that as long as the server isn't saturated, JSF also performs better than GWT. The GWT/JSF benchmark comparison is difficult though, since it's really important that the server for GWT also does the conversion and validation of data in the postback that JSF does. This is something you simply can't leave out in practice (never trust the client). Also, for the GWT vs JSF/Wicket graphs, it should be taken into account that the browser's rendering step is trivial for JSF/Wicket (since they mostly serve ready-to-render HTML), but the GWT client still has some work to do after receiving the server response.
One of the major performance/scalability issues that old JSF versions (prior to 2.0) had, was abusing state saving by putting way too much data in it. Things that absolutely should not have been there where put into it (like constants such as 'foo' as in <my:tag attribute="foo"/>).
JSF 2.0 introduced the partial state saving mechanism, which means only delta state is being saved. In practice this can be very little and reductions of two orders of magnitude compared to JSF 1.x are not uncommon.
After years of using JSF, I can say that except for saving too much state in JSF 1.x, I've never run into any performance issue that I could attribute to JSF. Any performance problems we ever had were always rooted in the DB and/or how we set up back-end services, wrote our queries, etc.