Five drawbacks to choosing JSF as your web application framework

Being packed as part of the Java EE web profile, JSF is a compelling web framework to choose, but here are five reasons why you might want to think twice about using JavaServer Faces as UI framework for your project.

Development frameworks should make the job of software development easier, but when the framework tends to get in the way of delivering high quality software, you know you have a problem. JavaServer Faces has this problem, which is exactly why enterprise architects should be looking elsewhere when it comes developing a user interface for their applications. As for why an architect might want to avoid designing a solution that leverages JSF, here are five very compelling reasons:

1. Simple tasks become difficult

Time and time again, when developing user interfaces with JSF, tasks that could be achieved quite easily using JavaScript become a giant hassle. A simple example is a page that includes a set of radio buttons, and when a certain radio button is enabled, a data entry textfield becomes enabled as well. JSF provides a radio button component, and JSF provides a textfield component, but there is no clean and easy way to embed that textfield component within the radio button component. To do so requires either the use of some creative JavaScript or the creation of a custom JSF component.

This simplest solution is to use JavaScript, but if JSF if supposed to be a server-side web framework, why are so many JSF problems solved by using the language of the browser? And while an option to create a custom JSF component is always available, rarely does a software development team that is working on tight timelines have the wherewithal to design, develop and properly test custom components, all of which leads us into the following strikes against the framework.

2. JSF lacks flexibility

Time and time again the JSF framework lets the developer down instead of rising to the occasion. A perfect example is the error messaging framework, which provides four alerting levels: info, warn, error and fatal. "On my last project, the application was using the four FacesMessages effectively, but the business unit needed to add a fifth," said Hiren Dossani, a software consultant specializing in the banking industry. "Unfortunately, JSF doesn't provide facilities for adding on a new FaceMessage alerting level." For Dossani, the problem could only be resolved by either rewriting the alerting mechanism, or dropping the business requirement. Since deadlines were short, the requirement ended up getting dropped.

This type of inflexibility stalls projects, whereas a good web framework propels projects forward.

3. The learning curve is steep

Getting a simple Hello World application up and running in JSF is fairly easy, but taking just a small step out of the shallow end of the JSF pool can leave developers significantly out of their depths.

"I've worked on a number of JSF applications, and every single developer has encountered the ubiquitous ViewExpiredException," said Swathi Raman, a software developer with Tech Mahindra. "Whenever I ask a developer as to what the ViewExpiredException means, they have no idea. They know to open and close their browser to fix it, but as far as what is going on behind the scenes, there is very little understanding."

JSF does a lot of interesting stuff behind the scenes, but very few users understand it or appreciate it. That means troubleshooting complex problems becomes impossible, as developers often don't even know where to start.

4. Incompatibility with standard Java technologies

Another key problem with JSF is that it doesn't work well with other standard Java libraries, with the Portal API being one, and JSTL, Java's standard tag libraries, being another.

JSF's uses an elaborate lifecycle model which includes stages like restore view, process events, update model values, invoke application and render response. Non JSF components are oblivious to these stages, and will execute on their own, without regard to what JSF is doing. As a result, values JSF might be expected to make available to the UI aren't available when various UI components, such as JSTL tags, execute. When a new tool doesn't play well with standard ones, it's a problem.

5. Primitive Ajax support

JSF 2.0 introduced Ajax support for basic interactions with components, but more complex Ajax based interactions, especially ones that work with UI frameworks like bootstrap.js and ember.js, are onerous. But more importantly, the templating framework, Facelets, is all static and provides no built in facilities for switching between faces asynchronously. This is a massive drawback when attempting to develop sites that provide a single page interface, or a portlet based type of experience.

It's frustrating to say, but as web based software development has evolved, JSF has not. With so many other web frameworks available, such as Node.js, ClojureScript and Angular.js applications that connect to RESTful backends, it's difficult to look kindly on the JavaServer Faces framework.

You should follow Cameron McKenzie on Twitter: @cameronmcnz


Interested in more articles and opinion pieces from Cameron McKenzie? Check these out:

Dig Deeper on Java application servers

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

The story about "A perfect example is the error messaging framework, which provides four alerting levels: info, warn, error and fatal." was very interesting.

At first I was trying to remember logging frameworks that didn't have those four levels, then remembered a similar experience in early .net days. I remember hacking a back way to update Site Map data dynamically once.

Talk about a pain.
I'll try not to be too combative, but I really question the author's experience using JSF as this is full of misinformation and faulty logic.   Point by point:

1. The assertion that because JSF is a server side framework that the use of JavaScript is out-of-bounds, and that somehow the answer to the problem is to...use JavaScript...just seems like faulty logic.  Use javascript. If you need to scale it across a team of devs, make a component. 

2. This is nuts. Don't use the faces messaging system if you don't want to.  What standard messaging do you have in JavaScript? None would be the correct answer.  JS framework X lets you customize message alert levels? Great, but does it work with JS framework Y? 

3. True for ANY sufficiently deep framework.  If it's not deep, it probably doesn't solve real-world complex business problems.  With that said, with JSF templating, components and maven archetypes that we use in our enterprise, we have developers building complex applications in minutes.

4.  Just not true.  Compatible with all sorts of Java APIs.  The two mentioned: Porlet API sucked from the beginning; JSTL works just fine as long as you understand its part of view rendering process and not part of the lifecycle. And there are plenty of JSF alternatives for JSTL functionality. And again, what is your alternative?  Is AngularJS aware of the Portlet API?  Of course not and who cares.

5. Flat wrong.  Its very mature Ajax support and we use it every day. Spend some time on the Primefaces show case.  Facelets is not static either.  I personally build a bootstrap single page application with JSF and Facelets because I wanted to use a commercial bootstrap template.  Worked just fine.

It seems you started with a conclusion and wrote up some points
in an attempt to make the case JSF was an old tired tech. 

I'm certain a case can be made for JS apps and RESTful
backends over JSF, but this just isn’t a good case.  I think where the
pros and cons shake out are in how many applications you have to maintain and
how much re-use you want to get in maintaining those.  For a shop that
maintains a single application and/or provides SaaS, by all means pick
whatever works best for you and consider potentially more scalable single page
application frameworks. 

But in an enterprise where you have 20-30 home grown
applications, teams of developers and you desire consistency across
applications and need to scale developers across teams, you need standardization
and you need re-use.  And component based frameworks (JSF,, etc)
give you that. 

Problems which is described here actually can be solved easy .
I do not think what business need 5 or 101 level of error alerts in the frontend, actually JSF implement standard logger levels.
Another framework which is pure java script, does not connect with java, and I cant imagine banking application which is use angular js and wasting a lot of time for creating calendars and forms, and do not care about security.
If your core front end is JSF you can use any js like react or angular. And also not any framework interact with another. For example you cant integrate Apache Struts and Wicket!!! You cant integrate maven and gradle. 
And not all application need use REST! If you choose angular you should call java backend via REST. With JSF we can have different types of architecture.
At the moment JSF2.2 with Primefaces still the better front end web.(Angularfaces?Omnifaces? AngularBeans?Prettyfaces?)
I've read it all. PEBCAK. JSF is currently the best choice for intranet Java applications developed mainly by Java developers. You don't recognize usecase for which JSF is good and for which it isn't. Therefore information value of your article is poor and I hope you will not confuse some newbies.