Five drawbacks to choosing JSF as your web application framework

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:

• Why the Amazon S3 outage was a Fukushima moment for cloud computing
• Software ethics and why ‘Uber developer’ stains a professional resume
• It was more than user input error that caused the Amazon S3 outage
• Don’t let fear-mongering drive your adoption of Docker and microservices?
• Stop adding web UI frameworks like JSR-371 to the Java EE spec