There’s this guy, Peter Thomas Peter Thomas headshot, and he has this blog entry called “jsf sucks”. I don’t want to increase his page rank so I’m not linking to it here. However, it’s certainly a popular page since it’s the top link for “jsf sucks” on google, bing, and Yahoo!. I have read the entire blog entry, all of the entries linked from it, most of the comments on those entries, and some of the entries linked from those entries. It’s a testament to my faith in God that I can emerge from such an exercise without feeling a level of guilt tantamount to that felt (one hopes) by agenocidaire.

I started doing a quantitative analysis of the comments on each entry, summing up pro- and anti-JSF comments. I only did a spot sampling of four entries in this way and each of them came up with more pro-JSF than anti-JSF comments. I believe that if someone proceeded with such a rotten tomato style analysis, they’d find that most of the entries had more pro-JSF than anti-JSF comments.

The best summary of Mr. Thomas’s vituperous screed coms from Benny Bottema, in one of the comments on one of his posts, which I’ll quote here.

Concerning your point about a ‘comprehensive list of hyper-linked, verifiable references to comments by real people’: I don’t dispute that. I said it is an unbalanced pool of information, poisonous in fact. With ‘nonobjective biased site of propaganda’ I referred to the site owner who compiled the list. Anyone can put together a site, only referring to articles that say something sucks. That’s just immature. Also the names you refer to are irrelevant, old quotes in a time where JSF couldn’t be corrected by supplemental frameworks. Take Rod Johnson’s point for example, it’s a quote from 2004 about JSF. No mention of its potential or combinatorial qualities... simply JSF itself which I already admitted is flawed on its own. And this is used as ‘proper’ argument? Useless propaganda I say.

One sensible response to such polemical fulmination is to tag the articles as appropriate using del.icio.us tags. I have built atag bundle for this purpose. It contains the following tags

                                                                                   
Tag name
Articles with this tag express a negative opinion of JSF...
jsf-opinion-negativebut the opinion may or may not be substantiated.
jsf-opinion-negative-reason-complexitydue to its perceived complexity.
jsf-opinion-negative-reason-misunderstandingbut the opinion is based at least in part on a misunderstanding of JSF.
jsf-opinion-negative-reason-misunderstanding-componentsbut the opinion is based on a misunderstanding of how components work JSF.
jsf-opinion-negative-reason-misunderstanding-decorationbut the opinion is based on a misunderstanding of how decoration and extensibility work JSF.
jsf-opinion-negative-reason-misunderstanding-elbut the opinion is based on a misunderstanding of how the EL works JSF.
jsf-opinion-negative-reason-misunderstanding-eventsbut the opinion is based on a misunderstanding of how events work JSF.
jsf-opinion-negative-reason-misunderstanding-i18nbut the opinion is based on a misunderstanding of how i18n works JSF.
jsf-opinion-negative-reason-misunderstanding-lifecyclebut the opinion is based on a misunderstanding of how the lifecycle works JSF.
jsf-opinion-negative-reason-misunderstanding-markupbut the opinion is based on a misunderstanding of how templating and markup works JSF.
jsf-opinion-negative-reason-misunderstanding-persistencebut the opinion is based on a misunderstanding of how persistence works JSF.
jsf-opinion-negative-reason-misunderstanding-renderkitbut the opinion is based on a misunderstanding of how renderkits JSF.
jsf-opinion-negative-reason-misunderstanding-securitybut the opinion is based on a misunderstanding of how security works in JSF.
jsf-opinion-negative-reason-outdatedbut the opinion is based on outdated information.
jsf-opinion-negative-reason-polemicalbut the opinion is unsubstantiated and stated in an unhelpful manner.

In addition to the tagging, which I hope others continue to do using this vocabulary, I took notes on each one, which I now present here. Many of the notes say, “fixed in JSF2: <code>” where <code> is a key in the following table.

                                                                                                  
code
meaning
viewParamsthe View Parameters feature
ezcompcomposite components
ajaxJSF2 standard Ajax support
faceletsJSF2 standard Facelets
compcompatJSF2 standard component compatibility measures
select*Select* now take Collection of POJO.
exceptionHandlingJSF2 pluggable exception handler, better error messages, ProjectStage.
resourceLoadingJSF2 standard resource loader
bookmarkableJSF2 standard bookmarkability
navigationJSF2 standard implicit navigation
systemEventsJSF2 standard System Events
annotationsJSF2 standard annotations for most stuff
prgJSF2 standard support for POST REDIRECT GET
noWebXmlOn EE6, you don't need a web.xml if you are ok with /facelets/* and *.xhtml as your JSF servlet mapping.
elJavaEE 6 standard EL method invocation
flashThe flash scope
viewScopeThe view scope
stateSavingJSF2 standard partial state saving

[2004-03-04] JCP Releases JavaServer Faces 1.0
- I read this entire thread and there are just as many pro JSF messages as anti-JSF ones. Of course, you chose to extract only the negative ones. 

Also, in the "Programmers So Far Underwhelmed by JSF" article, there was also positive and negative and you only extracted the negative. 

You missed this, "If you would have talked 30 years ago to people programming in assembler, not everyone was happy seeing C come up," he told internetnews.com. "That's just evolution, putting layers on top of other layers, but it's our belief that with JSF we get a very powerful layer that makes things easier." 

"Krause expects JSF critics to quiet down in the next six to 12 months, when the first JSF-enabled Web applications start hitting the Web portals and sites. His product, W4T, will include JSF in the coming months, and expects other tool vendors to follow suit." 

This is exactly what has happened.


[2004-03-05] JSF: The Ultimate in Flexibility? Or Complexity?
Entirely outdated and somewhat polemical.

[2004-06-09] Improving JSF by Dumping JSP
We've done exactly that in JSF 2.0. JSP is a backwards compatibility layer only.

[2004-08-06] My JSF Experience
The threaded discussion has about 40% pro JSF comments, but you don't mention that.

[2004-09-20] Boycott JSF
Citing the bile blog? Come now! I love Hani, he's a rockstar programmer in my book, but the bile blog was always more about polemecism than content.

[2005-07-??] Gradebook Taming JSF 1.1
Mr Davis says, "For example, backing beans would do database queries when a getter hits a null value. In practice, that meant we couldn't really be sure when the queries were being done or to what purpose. Some DB queries were issued in the Apply Request Values phase, some in the Process Validations phase, and some in the Render Response phase. We'd unexpectedly display old data instead of freshening from the DB. Or we'd add a "rendered" check to a button and find that submits had stopped working." 

This is a misunderstanding of the JSF lifecycle. Hitting the database from a getter is never a good idea. In JSF1, you could use a PhaseListener to do this, in 2 you'd use a SystemEvent


[2006-01-20] JSF Burrito: More Complete List
"POST vs choosing proper HTTP verb (personal annoyance) Difficult to link directly to a specific page with specific content [especially the first page in an app]" 

Fixed in JSF2: viewParams 

Component writing is much more difficult than writing JSP tags (Rick Hightower convinced me of this at NFJS) 

Fixed in JSF2 

Small free component market (compared to Eclipse; probably side effect of #3) [or even delphi components] 

Fixed by 2008 

"What's the point of JAAS and all the other security advances made if we're advised to "throw them out"?" 

Who gave you that advice? I show a nice integration of JAAS and JSF in my JSF 1.2 book. Also, in JSF2, System Events work well for very fine graned role based access control. 

"Unit testing our pages is too difficult." 

JSFUnit works well here. 

"AJAX components are coming, but it's much more difficult to integrate it on your own." 

Fixed in JSF2: ajax 

"Templating seemed difficult to do with JSF" 

Fixed in JSF2 facelets. Also, Facelets has become the defacto standard for templating in JSF 1.x.


[2006-02-10] JavaServer Faces - why?
This is a largely fact-free polemical post. The comments have several well-reasoned favorable responses to JSF.

[2006-02-21] Usability problems in JSF
Thanks for including a post from our star expert group member Adam Winer. Adam was instrumental in bringing JSF to the level of success it currently has.

[2006-05-03] Where JSF and Portlets went wrong...
"(try using ICEFaces components with ADFFaces)" 

Fixed in JSF2: compcompat. This was a central focus of JSF2. We'll know it's fixed when all of the parties have released JSF2 versions of their libraries. 

"While third-party options (like Facelets) do make programming with JSF easier" 

Fixed in JSF2: facelets 

There were a number of positive aspects to this post but you chose to only extract the negative ones.


[2006-05-19] JavaOne: Google Web Toolkit vs. JSF
More than half of the comments on this blog entry are pro-JSF.

[2006-06-19] JSF Rough Spots
"selectItems tag is way too unflexible - it only takes a Map. You'd think you should be able to show a simple String array or a List of Strings, but no." 

Fixed in JSF2: select* 

"The EL should be able to, as in OGNL, create objects has it comes across the need to." 

This one I don't understand. The JSF EL has always done this. 

"Every JSF page must define and load its resource bundle. I'm probably getting this wrong, but AFAICT, this is required. If true, this seems redundant and inefficient." 

Fixed in JSF 1.2 (2007) 

"JSF exception messages weren't very helpful." 

Fixed in JSF2: exceptionHandling


[2006-09-08] JSF and RSFHistory
I note that RSF hasn't been updated since 13 September 2008 for its 0.7.4 release. Does anyone know if this is still an active project?

[2006-09-13] Geebis Blog: Wicket
"The biggest reason is that creating custom components in JSF can be difficult, especially if you want your components to have lots of javascript/css that it contributes to the page." 

This problem has been solved very well in JSF2. The combination of composite components and resources is a very powerful answer to this person's problem. Fixed in JSF2: resourceLoading 

Also, Ken Paulsen and Jason Lee wrote a nice article about how to do this in JSF 1.x at http://java.sun.com/developer/technicalArticles/J2EE/jsf_templating/.


[2006-09-16] Tinman and the Scarecrow
"In JSF, you cant copy-paste a url into a new browser and expect the same page to show up." 

Fixed in JSF2: bookmarkable. Also, the PrettyFaces JSF add on does this even better. 

"JSF has a rudimentary IoC container somewhat inspired by Spring; though nowhere near as powerful" 

Many sites have been using JSF and Spring in production for at least three years. Also, the IoC container in JSF was inspired by ATG Dynamo and in fact pre-dated Spring by a month or two in concept. 

The rational for this rudimentary IoC container built into JSF is to give a useful experience to JSF users that want to use straight tomcat. JSF + Tomcat was the lightest weight full stack IoC container when it came out in 2004. Much lighter weight than Spring at that time. 

Nowadays, you have many options here: CDI, Guice and of course Spring. 

"JSF uses absolute, declarative navigation enforced by lengthy XML, triggered by passing string-keys around--pretty piss poor design in this day and age and quite clearly a legacy of Struts." 

Fixed twelve ways to Sunday in JSF2: navigation 

"For some bizarre reason, JSF does not play well with the JSP errorPage directive." 

Fixed in JSF2: exceptionHandling. Not just that but there is a pluggable exception handler.


[2006-10-19] Faces: The emperor has no clothes
"Then the hell of linking pages together starts." 

Fixed in JSF2: navigation 

"Not trying to be sarcastic here, since Facelets is pretty good, but this complicates the hiring and education of the team and in fact invalidates the selling point of Faces 'being a standard'." 

Facelets is now the standard.Fixed in JSF2: facelets 

"The spec is heavily based on two things: POST params and (ugh) forward navigation rules, that are default. In my previous life forward was the exception, not the norm." 

POST is still the default, but it's much easier to do proper POST REDIRECT GET, or GET REDIRECT GET in JSF2.


[2006-12-15] Nightmares on JSF Street in Trinidad
This post has very little to do with core JSF and instead talks about the Trinidad JSF component library.

[2006-12-19] Reasons to choose Wicket over JSF and Spring MVC
"I liked its form handling and navigation support but I did not like all the javascript and extra markup that was inserted into every page without me asking for it." 

As Jason Lee said in the comments, all you need to do to not have JavaScript is avoid using h:commandLink. Now, with JSF2, you have the additional step of not using Ajax, because it's really hard to do Ajax without JavaScript (though I heard you can do Ajax with CSS and no JavaScript).


[2006-12-26] not enamored by JSF 1.1
I found this thread to be largely fact based. I think this is a great way to discuss APIs. Unfortunately, this discussion pertains to a version of the spec that is over five years old.

[2007-01-01] JSF in 2007
Here we can see the influence of Seam on people's opinions. Note that most of the good ideas in Seam went either into JSF2 or into CDI. 

In the TSS comments I see, "Above all I think the Java community need to get away from premature standardisation of APIs, and let time and experience decide." 

This has been my approach to developing JSF2 from the beginning, and I'm happy to see all the different ideas from many different sources in there.


[2007-01-18] Tech Talk: Ed Burns on JSF 1.2
"Make it trivial to design custom components. I am not saying make it easy. I am saying make it trivial." 

Composite components to the rescue. Fixed in JSF2: ezcomp 

"There is no "page load" event handler to do initialization." 

System events make this even more fine grained in JSF2. Fixed in JSF2: systemEvents 

As the author of this talk, I don't see how it supports your argument about JSF.


[2007-02-19] JSF is cool but it is too young and it has too many bugs!
We live in an age of super-heterogeneous development stacks. In this world it's very easy to run into situations where the various layers of the stack interact poorly. The author would have been well advised to check into one of the forums of the component libraries in the stack.

[2007-02-28] JSF Anti-Patterns and Pitfalls
Nice that you quoted Dennis Byrne's article. He was a leading light in the MyFaces development for JSF 1.2. 

Also, any technology has its collection of best practices and gotchas. The fact that those for JSF are so well documented shows its vitality. Let's take a look at Dennis's subsections. 

The Deja vu PhaseListener 

Fixed in JSF2: systemEvents 

XML Fetishism 

Fixed in JSF2: annotations. No XML is required. Not even web.xml. Annotations are available for everything according to the 80/20 rule. 

Thread safety 

These issues are inherent in distributed multi-user systems design. The same issues will arise for shared objects in any web framework that uses the Servlet infrastructure. 

Facelets Migration Challenge: Tags with Behavior 

Putting behavior in your tags has always been discouraged. Dennis is simply adding to that chorus. 

Law of Demeter 

This one has nothing to do with JSF specifically and is simply a best practice about EL. 

Code to Interface 

This one has even less to do with JSF or EL or web frameworks. It's simply an axiomatic truth: make as few assumptions as possible by depending as little as possible on specific contracts. In Java, that means using interfaces correctly. 

View state encryption 

Note that turning on view state encryption in JSF is as simple as setting a content-param. How do you do that in Wicket?


[2007-03-17] JSF - Still pretty much a steaming pile of donkey turd
The author clearly does not like frameworks where the UI is built declaritively with markup that stands in for anything. He prefers plain HTML. For him, Wicket may be better. Also, he mentions the error messages problem, which has been solved for years with facelets and now solved in the JSF2 standard. 

Comments have: 

"I would have thought minimum requirements for a web layer toolkit would include: 

- *not* being forward based, e.g. should support Post-Redirect-Get out of the box 

- *not* baking in view artifacts, like referencing JSP pages. Use logical view names and allow a view resolver to work out what view technology is being used. 

- Having a halfway decent notion of a conversation as well as rich *navigation*. " 

All of these are fixed in JSF2: prg, navigation.


[2007-04-16] JSF still sucks?
I wonder why you didn't extract this quote from Matt Raible, "IMO, Facelets is very easy to learn. " 

He also talks about "developer abandonment". Well, here we are now nearly three years later and there's more interest and development in JSF than ever. That's not very abandoned.


[2007-04-26] Creating a jsf div component
The article point out the steps that used to be required for building a custom UIComponent in JSF 1.2. None of these are required any more. A custom component can be just a single Facelet page.

[2007-05-14] A Wicket user tries JSF
"Wicket does not require any extra XML config like you have faces-config.xml for JSF" 

In JSF2, you don't need faces-config.xml. IF you're on EE6, you don't need web.xml either. Fixed in JSF2: noWebXml 

"Wicket does not require JSPs" 

JSF2 doesn't require JSPs either. Also, the .xhtml extension is automatically mapped to JSF. Fixed in JSF2: noWebXml 

"Navigation logic is performed in pure Java code which is much more..." 

JSF2 navigation can be done centrally or per-page but it's always declarative. JSF2: navigation


[2007-05-22] Rethinking JSF - The Real Problem
The discussion on this thread was too mammoth to review in my limited time. However, scanning through it, I see an even balance of pro-JSF and anti-JSF positions.

[2007-05-23] Six Things JSF Breaks (and How To Fix Them)
I like this post. It is exactly correct and none of the recommendtions he makes are onerous, except for the desire for completely standards compliant XHTML. For simple pages this is possible, but when you use advanced components it is hard to guarantee.

[2007-05-25]

10 Comments

  • ptrthomas Newbie
    • mwildam Newbie
      As I am still considering myself as quite new to Java - especially for web development, I looked at the most frameworks that are in the news on a regular basis. For instance tried JSF, GWT with and without Ext GWT, Wicket - I think those are the currently top rated frameworks. I find major drawbacks within all these frameworks. - In JSF I had troubles with accessing component data and GUI destroy-issues in the designer (using NetBeans of course) - some things not really intuitive here. Anyway, looking at GWT the compile time (in the background compiling to JavaScript) is awful slow already for a hello world type thing, not even trying to imagine compile time for a big application. I further had/have rendering issues with Ext GWT. I loved the Wicket because it got rid of all the XML shit (I really hate XML because in 90 % of the cases it is used in a field where other formats would do a better job - just of the fact that the format makes it impossible to write a performant parser) - I love that plain Java idea. However, I found that it lacks GUI elements (at least looks like that for me) and it is completely missing a GUI editor as GWT is that missing also on the NetBeans side (and don't know about the quality of the plugin for Eclipse). - And yes, WYSIWYG GUI design is an essential point for me. So I think, the optimum framework is yet to come, none of those I found is really making me happy. However, even after reading a lot of negative stuff about JSF I am quite sure that JSF would not be the worst decision. - I didn't settle for a specific framework yet. For those who now come over with the argument that for each project the best fitting should be chosen, let me say: I am working in a small company where it is extremely important that my components are reusable for other projects because often one customer is not willing to pay the real amount of work so that we have to count on multiple times selling things to create the revenue. So I cannot create the same things in different projects all the time for new (there are some elements needed in quite every app and so I would have to build same things over and over again for each framework). I am quite on the newest stuff (Java 6, NetBeans 6.8) and don't have legacy Java projects that would tie me to a particular framework. So I am also not prestressed. Decision is very hard for me, but e.g. when looking on this - http://www.youtube.com/watch?v=93uciX4eUbQ - I have doubts that web applications in general are way too hyped and I will think twice before setting up an application as web app. It's mostly the Windows development guys suffered from those plenty setup problems doing everything as web application now. But it could be so easy by downloading and double clicking a jar (or even just use a JNLP Java webstart link. Sure, there are applications that are supposed to be a web app - and I am still not sure which framework to settle on. Habe to try them all again I think. But my main message is: The existing frameworks are all great and all suck to some extent. But I am happy that I did not settle on .NET (although I come from Windows development realm) because there I have only one choice that ever works on Java too if I want to avoid any of those frameworks. //
    • tzwoenn Newbie
      First of all: I spent almost one day reading through Peter’s link list (almost, because some of the comments, posts, etc were already known to me) and Ed’s response. That was a great kind of work, to analyze and categorize nearly all of the not always that objective third person comments, without becoming polemic yourself.

      The project currently uses JSF2 (reference implementation) without any additional component library or extensions in a midsize project, that heavily depends on a custom design, a sometimes clumsy old CMS for editorial maintenance and third-party javascript integration for fancy effects. The underlying domain logic is complex enough for not being comparable with rather simple “example” applications like blogs or guestbooks.

      From my perspective Mojarra 2.0.2 seems to be more mature than the currently used and recently released DI container spring 3.0.0 and I suppose the quality (documentation, test coverage) of springsource products is one of the best around in the opensource world.

      Following Peter’s and followers pain reports, I have to admit JSF is indeed a highly complex piece of software for web application development. Not comparable with Struts in any way for example. If you are planning to introduce JSF for a new project, I would like to advice you to get some people with JSF experience for your team. With “JSF experience” I mean guys, who have actually read the specification, know why things do not behave as expected and could explain this other team members. In general the problem is not caused by JSF, but rather by the developer who misunderstood some of the concepts of JSF.

      From my experiences the creation of controllers, converters and validators and the usage preexisting component is not a problem for JSF unexperienced developers. There is none to little of API in form of simple interfaces or event classes to fiddle around with. But if you are going to change some of the fundamental behaviours of JSF, you need to get in touch with all these classes that are used in some phases or thoughout the whole request lifecycle. There are so many extension points in JSF, that even experienced developers often do not get the right point in the first place for their implementation requirements. I have not count them all, but making a rough guess I would say there are about two to three dozen of extension points for an application. These are mainly accessible via decorator or bridge pattern, that is why there are so many abstract classes are out there.

      Even though these extension points are one of the reasons for JSF’s complexity I love them. I love them because they enable my team to create awesome application with high level abstraction in general from protocols, states and so on in general, but the ability to extend at low level where needed.


      br, Sven //
      • phenderson Explorer
      • pjmlp Newbie
        Sun is now speaking everywhere about J2EE 6 and JSF2, but unfortunetely for those of us working on the field, these are dreams still far far away. On my job, I have to handle with JSF 1.2 applications that are running on top of JSP 2.0 (that's right, no typo) containers, thanks to Facelets and a few jar hacks. These are very important customers, but they won't update any time soon for a JSF 2, compliant container. And this  is true for many of us out there. //
          • fabmars Newbie
            So what? Almost every customer using Struts or Spring MVC or even plain Servlets won't take the risk to move to anything else either.
            It's better to start new projects with JSF2 than trying to convince your customers into upgrading the app they already spend millions on and which satisfies their need for the moment.


            Anyway, my point: JSF1.2 and JSF2.0 are great frameworks. I've been following JSF since 2004. Oh dear, JSF1.0 was far from perfect. JSF1.1 was much better already, and JSF1.2 just works fine.
            From there on, I consider JSF2.0 as a set of major improvements on something that already proved to be reliable and ready for production. I have myself put a few medium-to-big JSF projects into production without any serious problem during development or deployment. Indeed, if you take advantage of the extension abilities of the framework, and use Facelets (now standard), and RichFaces/IceFaces on top, you can build great websites really fast. Naturally you need to climb the learning curve, but it's not harder than any other framework.

            So many people criticize JSF1.0 in 2010...the same way they criticize EJB2 (regarding other CDI discussions). It's irrelevant and not worth commenting on.
            What if I started criticizing the Boeing Stratocruiser, initially based on a B-29 and released in 1950? Wouldn't you say I'm dishonnest not to talk about the 787 Dreamliner and its first flight last month?

            So many people also fail to understand a standard like JSF passes through a complex process in a whole EE release. It's serious stuff, it involves dozens of projects, hundreds of people, and puts the Java world at stake every time. And you need to make compromises. But the next version will fill the gaps, as with every other framework.... except other frameworks will evolve in beta version for years, regardless of any constraint or backwards compatibility...but it seems many wanna-be architects take the word "standard" as an insult. And it's just awkward and stupid.

            And some recurring arguments, like bookmarkable URLs are also irrelevant. I never had a problem with them. All you need to do is specify #{param.args} in the managed bean behind your page in faces-config.xml, write the appropriate setters in that bean, and handle the logic in a @PostConstruct...If you can't do it easily, you need to RTFM again. JSF2.0 makes it even easier. Great, we should be thankful for that!

            Personally I've stopped trying to convince people with prejudice to use JSF. If they don't want to use it, fine by me. I'm just expecting they leave me alone.
            There are other very good solutions for enterprise use or not (GWT, Flex, Wicket, etc) and I respect that. They are really cool stuff too, with strong points and flaws as well, naturally.
            However, I have personally seen Ed Burns making a presentation of JSF2, coding a few examples live, and literally convincing the crowd it was a really strong framework. THAT tells volumes. //
            • driscoll Expert