(WARNING: This article contains a fair amount of arrogance, bias, and perhaps some ignorance.)
Then came JSF. JSF promised to be the answer for Java web developers, who like me, didn’t really know how to do standard web programming. Implementations like Richfaces, Icefaces, and ADF Faces sprang into being. And with ADF Faces, we were promised that we could actually build pages with a drag-n-drop interface. WOW! Now we could build applications that looked like big boy web applications…without having to learn what the big boys know. We could even incorporate so-called Web 2.0 elements. WE COULD BE COOL, TOO. Sounds great.
But these are the reasons that I didn’t stick with it:
One: JSF isn’t easier than standard web programming
There’s nothing that you can do in JSF that you can’t do better with a basic MVC framework (like Stripes), a style sheet, and a few JQuery scripts.
Two: At the mercy of the implementation
JSF is extensible. Theoretically, you can build your own presentation layer components. I even took a class that showed me how to do it. But in reality, I never even attempted it. I just used the components that were available, and tried to make it work. But if I wanted to accomplish something that wasn’t covered by the JSF library I was using, I was just screwed. Even though I’d seen what I wanted in other web applications, I couldn’t always accomplish it with JSF.
Three: You’re cut off from the rest of the web community
Have trouble finding good support on JSF problems? How many web developers do you know who actually use JSF or have even heard of it? The vast majority of web developers code with HTML, CSS, Javacript on top of server side technologies like PHP, Java EE (not including JSF), and .Net. I would encourage you to consider stepping into the wider community of web development.
Four: The web is meant to be stateless
HTTP is a stateless protocol. That means the web is inherently stateless. If you try to make it stateful, then you’re creating a list of problems that have to be managed (memory, performance, keeping track of the state, keeping data fresh, etc.) JSF is a stateful technology. The state is maintained in a tree structure on the server side or the client side for EACH user session. If you use the client side, you have performance issues passing state back and forth for every request. If you use the server side to hold state, than you have to manage the memory used on the server. Perhaps it’s better to go with the flow and keep the web stateless.
Five: Be honest. Are you just using JSF as a crutch?
I used JSF because I was too lazy to learn the standard web toolkit. I was lured in by the pre-styled, pre-built drop in components. I wanted to continue using my java client skills. Java was the only thing I wanted to use because it was the only thing I knew how to do. I was using JSF as a crutch. There are good reasons for using JSF, but that is not one of them.
JSF is not all bad. It has lot’s of good stuff, like data binding, navigation, and validation. But JSF isn’t the only java framework that does that. Stripes does it, and does it much easier (as you can tell I really like Stripes).
I know this guy who has been very successful with JSF, but I received a very weird question from him once. He asked me how to build a basic alphabetical navigation for his page. I guess RichFaces didn’t have one of those components. I told him that it just took a little HTML. He asked me if I could send him some. I was embarrassed for him. He had been developing web apps for years.
Don’t be that guy. Pick up a few books. Read a few blogs. Learn how to develop web pages. Don’t use JSF to avoid learning the web.