It seems like once a month or so, someone comes out with an article about the ‘real’ problem with JSF, how JSF is dead in the water, or how bad it is. I think uninformed articles like these are the biggest problem with JSF right now - go to a JEE forum and read JSF threads, and you’ll see the same unfounded, out of date, and inaccurate reasons why JSF ’sucks’. There are certainly a lot of things that could be improved in JSF, and I agree there are a number of things which are frustrating (radio buttons, anyone?), but a lot of articles tend to focus on old problems or the idea that “JSF doesn’t work the way I think it should”.

Probably the biggest misguided complaint is that JSF components aren’t coarse-grained enough, or that “there isn’t a component that does x, y, and z so JSF must suck!” An article on TheServerSide is the perfect example of this. In the article, Joseph Ottinger asks why there are no login or search components, and points to wiki and forum components from ADF (which are not publicly available yet, to my knowledge) as being perfect examples of what JSF should be. Why are all 4 of these perfect examples of bad candidates for JSF components? The whole point of a component is that it is a reusable piece of functionality. With every piece of layout and functionality you try to encapsulate into a component, you make it harder to reuse.

Let’s take the login component as an example. At its simplest, a login screen in JSF is composed of: a input text component, input secret component, and a command button. There will be a backing bean, but it will be extremely simple - the real work goes on in a method the backing bean would call, and could not reasonably be abstracted into a component. Making a component to encapsulate that would seem easy, but how do we allow for positioning of elements? How do we allow customization of the input text and secret boxes? My system may only allow 4 digit passwords (ie, like a PIN), and yours may allow 20 digit character passwords but only 5 digit numbers for the login. Already, we have a fair amount of complexity to take into account, and it hardly seems worth it when you realize how easy it is to do this without a component. Then what happens once we start adding in stuff like: allowing registration, resetting forgotten passwords, saving passwords, captcha validation, various error messages, etc?

The other examples are equally problematic - several of us discussed  the search box example in discussion for the article. What you ultimately end up with is a new API someone has to learn for each component, possibly a templating language on top of JSF to allow for customization, and components that are not really that reusable. How do you reuse functionality like that? Well, on a per project (or perhaps, per company) basis, you can create custom components (and their far easier cousin the composition component available in Facelets) to do these tasks. That way, they match the design and functionality of what YOU need.

Over the several years I’ve done JSF development, I’ve found few cases where I felt like I had to write a custom component. I’ve had great success with reusing functionality with composition components, and achieving most tasks with the standard component set has been quite easy. In fact, the most frustrating experiences I’ve had have been trying to integrate coarse-grained components into an app that had already-existing design requirements.

If someone can show me a good prototype of a coarse-grained JSF component that is highly reusable, I’d be willing to change my tune, but I’ve yet to see one. And, for the record, I don’t think this is a problem specific to JSF - when you look at other web frameworks, acheiving reuse with big monolithic functionality is just as difficult.