A critic view on JSF Framework
April 28, 2008 13 Comments
JSF is becoming more popular framework for user interface layer development, many architects and companies assuming that Struts is becoming outdated and JSF is catching up the market. I am not sure whether it is true at this point of time. However I would like express my critic on the advantages and disadvantages of JSF.
Advantages
- Big vendors (Oracle, IBM, JBoss, etc) backing JSF implementation like EJB. Can expect good level of support and quality components from these vendors.
- By design and concept it allows to create reusable components. That will help to improve productivity and consistency.
- Many quality and ready to use components are available from Apache, Richfaces, Infragistics, Oracle, etc.
- The concept of action and action listener for button invocation is good.
- Has very good support for EL expression that improves the user interface code readability.
- The concept the validator and converter is excellent. Unlike struts JSF keeps the validation logic very close to the component declaration.
- JavaScript code are embedded as part of the component; this keep less confusion for developers and more re-usability on JavaScript code.
Disadvantages
- There is no benchmarking report or promise from Sun Microsystems about the performance of JSF framework. By seeing their concept I believe it is not suitable for high performance application.
- The specification doesn’t consider bookmarking facility.
- Hardly a very few examples available for developing dynamic pages including new component and removing a component from a page based on business rule.
- Every button or link clicked results in a form post. That’s just wrong – why can’t I have true links like the web is supposed to? Form submission for page navigation make complex coding for simple requirement like Cancel button. Read here to know the work around.
- Datatable component requires same data from bean on restore view phase. If the data retrieved from database, this will have impact on performance. Click here to know more about this issue.
- There is no tight coupling between managed bean and phase listener. This is a major drawback of JSF which makes JSF phase listener feature unusable.
- Default error message is not good. Need to customize the default error message.
- Not Scalable. It uses session object to store the component state across the request. In server farm environment it is too costly to replicate the session data.
Bottom Line
JSF simplifies user interface development, and increases complexity on request processing lifecycle. At this point of time I don’t see JSF as a matured solution.
Venkat Sadasivam 
Good points, but one question:
“Every button or link clicked results in a form post. That’s just wrong – why can’t I have true links like the web is supposed to?”
Does the outputLink tag not provide what you’re looking for here?
– Jonathan
I can use outputLink but I cannot pass any parameters to my bean. I have manually handle request parameters.
http://www.comesolvego.com/2008/05/03/game-over-java-server-faces/
Well yo being very wrong here. Of course you can have normal link in jsf h:outputLing is just fine, And yes you can map its values to bean either reading from the request parameter or on faces-config like name valuen pair when defining bean using el.
nameOfBeandparam
#{nameOfRequestParam}
I am not sure about a syntax.
You can beans inside PhaseListener from FacesContect you can even use EL and get them by name.
just posting once again, it seems the site did not like angle brackets.
I am not an expert in JSF. I did my own version of MVC framework which is better in someways than struts and it definitely lacks certain things,
actionform for example. I was looking around for something better before I started a new project. JSF caught my attention.
I found somethings interesting but then after going through few articles and tutorials I found that there are some limitations and its
highly possible that it could be because of my lack of knowledge. 1) All the examples I found had (to-view-id) destination as a page.
I am not sure if we can redirect to a java class. 2) To expect all the processing can be done in a bean class seems naive especially
when the logic is complex and data/rules must be shared across multiple beans.
However, unlike struts, JSF’s navigation seems to be 100% controlled through an xml file. Although I don’t know if (from-view-id) is required.
If so, then that seems an unecassary thing. It would make much more sense to start with a command rather than page as the initiation process.
But like struts, by making navigation file part of war file it has the limitation of requiring a new deployment if navigation needs
to be changed. It would be so cool to load this navigation from a DB.
I tend to agree with Venkat on the conclusion.
Venkat, I see this article was published in April 2008. What do we know now after 1 year in April 2009? Is JSF becoming viable option or still have issues? Have they addressed any of concerns you have mentioned?
We are in process of deciding whether to use JSF or plain MVC model. Any advise will be greatly appreciated.
Sincerely,
Uday
I am not using JSF any more. However with JSF2.0 spec nothing much changed. In my view JSF don’t have any future, Sun will bet on JavaFX.
Guys,
Check out Richfaces and see what you can do with JSF with ease.
http://en.wikipedia.org/wiki/Richfaces
— hardtobeagod
What are you using now if not JSF? Did you find something that works better?
Hi Venkat,
And what do you think of Stripes?
Regards,
Agus
I haven’t worked nor reviewed Stripes. My guess is it won’t be as bad as JSF.
Lately I started liking component based Wicket framework as I have to write lot of Java code and less HTML/JavaScript code.
I had bad experiences with JSF too. But this might be because I was using myfaces (+tomahawk + trinidad) which was clunky and very buggy!
It seems to me sun is/was pushing JSF to sell there GUI creators for JSF ;-)
So my personal suggestions are:
either you go the ‘new’ JSF line with JBoss(richfaces)/faclets/whatever
or you try better/real component based frameworks like wicket or vaadin.
Wicket has only Java + Html and Vaadin has only Java has its programming language. So, no new proprietary xml tags (JSF tags), no Javascript or whatever and full crossbrowser support.
Hі there, I log on to yoսr ƅlog like еveryy week.
Your writing ѕtyle is awesome, keep dߋing what you’re ɗoing!