My reply to “Top 10 reasons why I don’t like JSF”

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.

Written by Posted in JSF Tagged with

14 comments

  1. Kai Wähner

    [quote]
    This is true. It makes more sense to compare JSF component frameworks such as RichFaces against other frameworks.
    [/quote]

    Here, I disagree with you!

    You have to compare JSF to Wicket, Tapestry, GWT, and so on…
    Or you have to compare JSF and RichFaces (or ICEFaces or PrimeFaces or …) to e.g. GWT and SmartGWT (or ExtGWT or …).

    Otherwise that is no fair-minded comparison.

    I agree to your other comments…

    Best regards,
    Kai Wähner (Twitter: @KaiWaehner)

  2. Hendy Irawan

    Hi Max,

    Great writeup! I agree with all of your points, and disagree with most of his views (although technically they’re valid complaints).

    However I don’t agree with. “In conclusion, JSF is not perfect, no framework is.” The purpose of a comparison is not to declare whether some framework is perfect or that some framework is all bad.

    It’s to analyze its strong points relative to another framework(s) which have weaker areas. I would love to know despite these 10 ‘hate points of JSF’, there should be some hate points JSF still does better (i.e. “yeah it’s bad, but others are worse”) than some other framework.

    Also to analyze its weak points (in the case of JSF which is the subject here), also relative to other framework(s) which can do better. I guess this is the most useful.

    For example, referring to point 10 “the web is fast, standards are slow” I think the recent standards somewhat admit this, and provide mechanism to solve this “problem.”

    RichFaces, IceFaces, PrimeFaces, the versatile PrettyFaces, and the Seam project is a testimony that the standard itself (be it JSF 1.2 or JSF 2.0) is not the the only thing that matters, innovation can still (and will always) happen elsewhere. It just happens that the JSF is the core functionality that we can kind of rely on.

    The CDI spec addresses precisely this “standards are slow” problem. It does not try to be everything, but it embraces everything that can be developed on it (CDI Extensions).

  3. erik

    You know, reading more and more of these “pass personal opinion as fact blog A, counter with other personal opinions in blog B” type of situations: I wonder if there are blogs made by carpenters where they complain about the properties of specific hammers and saws?

    I don’t think so, I’d gather they focus more on what is really interesting: what you actually make with the tools and how. That is something I sorely miss in today’s development community. Too much focus on the tools (and far too much complaining and comparing), not enough focus on actual development :/

  4. Eelco

    @Erik

    If you like to make the comparison with other professions, you should pick say architecture & builders, and compare framework choices with the choices for building patterns and materials. Making wrong choices there can be devastating for the projects, just like making wrong (or maybe I should say sub optimal) choices when it comes to frameworks can wreak havoc on software projects.

    Another difference with carpentry is that while it isn’t part of the regular job of a carpenter to build a good hammer to help with his job, in software, building or ‘buying’ frameworking is as much part of the job as applying those is.

    Finally, we should have discussions – even the ugly ones – in order to keep pushing our still rather immature profession/ industry forwards. Languages, frameworks, patterns… these all would never improve were it not for people getting upset with current ones and venting that frustration through discourse or by building their own – hopefully rounder – wheel.

  5. RichFaces developer

    Hi Max,

    can You talk about “back button” problem? I don’t want use Seam, I develop my applications in RichFaces. Can you give us the solution of this problem in a RichFaces application? Maybe, there is a solution in the RichFaces demo application?

    Thanks in advance

  6. max

    @Kai @Hendi @Erik @Eelco: thank you for your comments. My goal is really not to do another this blog vs this blog or this technology vs this technology. I’d like to give a more fair view on JSF. Unfortunately, the blog to which I replied is not a very fair representation of JSF and only creates more confusion.

  7. Tracie Wells

    You know, reading more and more of these “pass personal opinion as fact blog A, counter with other personal opinions in blog B” type of situations: I wonder if there are blogs made by carpenters where they complain about the properties of specific hammers and saws? I don’t think so, I’d gather they focus more on what is really interesting: what you actually make with the tools and how. That is something I sorely miss in today’s development community. Too much focus on the tools (and far too much complaining and comparing), not enough focus on actual development :/

  8. RichFaces developer

    Thank’s a lot.

    Maybe back button functionality is solved by using of com.sun.faces.numberOfViewsInSession and com.sun.faces.numberOfLogicalViews parameters in JSF’s web.xml? Earlier, I turned off page caching in my intranet applications.

    I not used JSF 2 but in Your blog I see that JSF 2 has got “page params” i.e. GET submit. It’s great. I think, that is the best solution for back button.

  9. Nicolas L.

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

    It sounds wrong to me.

    Developpers want consistency between frameworks based on a JSR.

    Different behaviour has a cost and it means “inner” experience.

  10. max

    @Nicolas L: JSF implementation is based on JSR, 3rd party extensions are created based on standard ways to extend JSF and this is the place where differences might occur.

  11. Pingback: Reply to “Top 10 reasons why I don’t like JSF” | Brent Sordyl's blog
  12. Pingback: Softwareberatung M. Höpfner | JSF vs. GWT + GXT

Leave a Reply