Bruno Borges posted Top 10 reasons why I don’t like JSF. Below you will find my replies to his points. A few weeks earlier, I also posted: JVM Web Frameworks Comparison – reply to JSF scoring.

1. Extra step when defining a project’s architecture
People insist on comparing JSF with other frameworks. They should stop doing that. You can compare MyFaces to RichFaces to Tapestry to Vaadin to GWT.

This is true. It makes more sense to compare JSF component frameworks such as RichFaces against other frameworks. And because the component libraries are all based on JSF, you will also be comparing JSF. However, I’m guessing most people already do that, they compare JSF+framework vs framework XYZ.

JSF is a specification, not a final product

JSF is both. It’s a specification and there are also two implementations, Mojarra (Oracle) and MyFaces (Apache). Both implementations are final products which you can use to build applications (but most projects use a rich component framework on top of the implementation).

Vendors too insist on marketing JSF as a Web Framework. But they forget to mention that you will be locked-in to their implementation because of lots and lots of non-standard components. It ain’t cool.

Again, there are just two implementations, Mojarra (Oracle) and MyFaces (Apache). You should have no problems replacing one with another if needed.

On top of the specification, there are a number of frameworks such as RichFaces, MyFaces Tomahawk/Trinidad, PrimeFaces and IceFaces which provide Ajax components, skins, and other features.

Lastly, using any web framework locks you in whether it’s open source or not. Believing you can use GWT and somehow magically replace with with Tapestry?

You spend a week comparing *one* JSF implementation with other frameworks, and if you chose JSF, you then realize you have an extra step: you have to pick a vendor, an implementation, and then goes another week of POCs, tests and evaluations. And you’ll be locked. It is not easy to move from one to another. Specially when you have to use those non-standard components to turn your project on something really functional.

I doubt anyone really compares just JSF against any other frameworks. It’s almost always going to be JSF + rich framework. The goal of JSF is to define a very expendable foundation or the core and then let companies build additional rich components and features on top of the standard.

2. Fragmented Community
Now, let’s say you, developer, works on a project for 6 months, on top of RichFaces. Then you move to another project built
on top of MyFaces. Yes, you will have to sign in to another mailing list. To another forum. Different from other products, JSF has no centralized community. If you are working with Wicket, you go to users@wicket.apache.org. If you are working with VRaptor, you go to their Forum. If you are working with JSF, you will need to sign up for at least 3 different mailing lists, sign up for 3 forums and probably, tens of blogs.

Disliking JSF because you might have to sign for multiple mailing lists – well, sounds a rather immature. If there was just a single component library available for JSF, we would probably hear that you don’t have a choice and would be locked using it.

It is not easy to ask for help on a fragmented community. If you face a problem with RichFaces, when you were used to work with ICEFaces, you might end up asking something stupid, and probability is you will be told of a different solution to the same problem.

This doesn’t sound like a valid argument. If you are a serious and experienced developer, you know how to find help on the Internet.

3. Fragmented Documentation
If community is important, imagine documentation. You must have bookmarks of all JSF implementations. If you work with GWT, you need only one. If you work with SpringMVC, just go to springframework.org. Also there’s the problem of non-standard components. Let’s say you are working with Seam, and you have to bind some component to some RichFaces component. Where will you find a documentation about that? There’s no such thing. If you are luck, you might find some blog post on Google. Odds you won’t find. You will discover by yourself after hours of debugging and tracing, and in the end, you will not blog about that too. You will just move on.

All you really need to bookmark is the JSF reference documentation from Oracle. Every component library that extends JSF, there is usually a single place where you will all the documentation. There are also great JSF resources such as http://javaserverfaces.org and http://jsfcentral.com.

4. Component Incompatibility
Well, there’s not much to say on this. JSF 2.0 address some issues, but not all of them. Component interoperability between different components can’t be easily documented because of JSF’s nature. This (documentation) also happens on some non-standard frameworks, but there are others that the core architecture helps a lot the developer to just don’t care about this. Wicket is one of them. Components are grained and independent. If you want to interoperate different components, you simply share a Model or deal with events.

Component interoperability in JSF 2 is much better. Interoperability issues exist in JSF 1.2, but I also know projects where RichFaces and MyFaces components where used in the same application without any problems.

5. Caveats on some scenarios because of different implementations
This one I heard from a JSF developer. He said RichFaces fires rendering updates in a different way to MyFaces Trinidad. If the developer must be aware of that, odds are you won’t find proficient JSF developers.

This it true. But, if you an experienced developer and know core JSF well, you will have no problem picking up the differences.

I pointed about this one at the Web Frameworks discussion at JavaOne. It is not easy to find a Wicket developer, or a Vaadin developer. But when you find them, probability is they will be proficient, or at least above regular web developers.

With JSF, which has tons and tons of job offers around the world, but lots of implementations and caveats, probability is that you will easily and quickly find a JSF developer to hire, but he or she won’t be proficient. They will be regular developers. I’m not saying this is 100% true. Of course it is possible to find a proficient JSF developer. But with different implementations, it is hard to find one that knows all about of their tricks, tips, issues and secrets.

To make such statements without any proof or concrete numbers is meaningless. There are always experienced developers and inexperienced developers with any technology. Good developers is hard to find in general. Too many people are just placing key words on the resumes or profiles. Here is a good post on this topic: Good developers program in a language, talented developers code.

8. Non-functional prototype
Ok, not a big deal. But it sucks a lot when your web designer changes the UI and you must merge those changes. What if you had a functional prototype you can share with your Web Designer? Some frameworks do that. Tapestr and Wicket for example. The output is HTML, your are building HTML, your designer gives you HTML, so why not take advantage of that work done on a previous stage?

This requires a well designed Facelets template and experienced developers. Tiggr might help with rapid prototyping.

9. Performance
Just Google for benchmarks comparing JSF with any other Java Web Framework. The lifecycle is just huge…. 😦

The lifecycle is not huge. Similar life cycle happens in any framework. You get new values from the request, you convert and validate them, you apply values to model, invoke application logic and render the result page.

10. Web is fast, standards are slow [more]

True, but that’s just how it is. With somewhat slower standards, you get a very active JSF community with a large selection of rich components, and extra features to make JSF better.

In conclusion, JSF is not perfect, no framework is. JSF 2 is a major upgrade over JSF 1.2 and if you include a rich component library such as RichFaces (and plus Seam) you get a pretty powerful tool set for building Java web applications.