There is a lot of fear, uncertainty and doubt about JSF. Thats nothing new. Beeing a JSF developer you have to deal with that FUD. But where does it come from? A lot of FUD is created when developers are told to use JSF when another framework is more appropriate. Its frustrating to have to eat soup with a fork because some marketing jerk told your boss that spoons are evil.
JSF is not Swing for the web!
A simple example: I talked to people that chose JSF because they were told it was “just like Swing”. If you are an experienced Swing developer who never had anything to do with the web, this sounds good. But imagine the problems you will run into when you discovere that a ValueChange listener is not aware of client side events. Instead, it is invoked on the server side, before a beans property settter method is called, demanding that a request needs to be sent. While it is not a problem at all to catch also the client side value change event, this is totally different to how Swing works and you need a basic understanding about the JSF lifecycle. Only view marketing arguments did so many harm to JSF’s reputation as the “JSF is like Swing” statement.
Its all about false expectations
From all the many ways how false expectations may arise, wrong marketing arguments are the most annoying ones to me. Where do they come from? Lets look at a recent example at the Oracle Technology Network: JSF 2.0 for the Cloud. In this 2-part article the author describes JSF 2.0 features as “ideally suited for the virtualized computing resources of the cloud”. Here are the authors points on why JSF is “cloud ready”:
- Ability to use REST-style GET requests No kidding! I doubt there are web frameworks without …
- Ajax Really. My favourite quote: “Ajax support in JSF 2.0 is integrable with Software as a Service (SaaS) by providing interactive browser-based Web applications.” Thats great stuff. ;-)
- Cloud vendors offer support for JSF Well, some of them do and some of them dont. GAE does, but it also supports other Java web frameworks and even Python, so I dont see a plus for JSF here.
- Annotations They are convenient but how exactly are annotations relevant when it comes to architecture?
- Path-based resource handling The author describes JSF’s resource loading mechanism as huge improvement on loading resources with
getClass().getResourceAsStream(). (?!!!?)While JSF’s resource handling is surely more convenient, this has, again, nothing to do with cloud based applications.
- Implicit navigation ?!?
- Event handling You know, there is no cloud without events! ;-)
You dont have to use a simple servlet container…
Besides the architectural confusion, the author suggests to follow a code example. To do so you just need to download some essential ressources. These are:
- Oracle JDeveloper 11g (Download size 1.2 GB for the studio edition)
- WebLogic Server 11g (included in JDeveloper 11g)
- Oracle Database 11g Express Edition (312 MB)
This reads as “To get started with a simple JSF example , just download 1.5 GB of heavyweight components”. No wonder JSF is peceived to be heavyweight and hard to learn. The features describe can easily be demonstrated with a simple servlet container. If you want to test it in the cloud, here you go!
The author of the “JSF for the cloud” article failed to bring up a single point why JSF is better suited for cloud based applications than any other web framework. Instead he created a promise: “JSF is cloud ready”. Whatever this means, there will be people drinking the Kool-Aid without consideration of the questions that should have been asked when moving to the cloud. How about scalability? How about multi-tenancy? I am not sorry for those who don’t do their homework (consultant jobs pay my rent), but for the negative reputation created by the buzz about their predictable failure.