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:
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
1. Simple tasks become difficult
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