Link Details

Wow, I'm truly surprised about how many people voted up this rant. In my honest opinion the author is wrong on so many points, that it's hard for me to understand that anyone who has actually used JSF for some time can vote the article up. Just to list some of those points here too:

---
Take for example your point 2 - "Little control over custom components [...] If you want to change this, you have to rewrite the component."

This is actually the exact same situation as with object oriented development. Someone provide a class that you can use as-is and which may provide some options for configuration. If these limited options don't suit you, you can either extend the class and override some of its functionality or you can indeed write your own class. Take something in standard Java like the HashMap. There are some configuration options available like an initial size, but not a maximum size. If I wanted to have that, I would need to do some extra stuff.

Now by your logic, we should dispose of the OO concept and go back to procedural coding? Just because the HashMap does not come with some configuration option you grave for, the entire OO concept is wrong?

Maybe point 3 says enough: "Development of custom component? No way, extremely complicated."

It's not 'extremely complicated'. Maybe it is for you, and maybe you should look into another profession where things aren't that complicated? Developing a simple custom component is as easy as inheriting from UIComponent and spitting out some HTML. Yes, there is some mundane work involved when you wish to use the component on a JSP page; you need to create a taghandler and an entry in a tld file. There are however two things to remark here: First, this is NOT extremely complicated. It's just mundane work. But far from being complicated. Secondly, JSP is -a- view technology, not -the- one and only. JSF in its core has absolutely no JSP dependencies. Defects in JSP -are not- automatically a defect in JSF.

About 4; you probably just don't understand the life-cycle. If you have fetched some data from whatever in your request scoped bean, it's simple there for the duration of your request. If your code is stupid enough to refetch it from the original source when it's already available inside your bean, then it's just your own code that's being stupid.

This is actually a similar situation with using a cache, say OSCache or Jboss cache. If your code fails to check the cache for availability of an item, but always tried to get it directly from the data source, would you blame OSCache that it's concept of caching doesn't work? Please wake up dude. It's YOUR code that needs to check whether something is there in the cache or not. If those checks happen more than once, abstract it to a separate method that does this checking and let all of your other code only use this method. Don't blame library code for things you are doing wrong!

And 6 is really hilarious: "JSF always do the POST". I take it you mean "JSF always does a POST", but still... take a look at Virgin's online store at: http://www.zavvi.co.uk/ A JSF site, with guess what... GET requests everywhere. Technically it's quite simple to do this; in your managed bean declaration, just bind your bean properties to param.somerequestparam and that's it. Instant GET support for your pages.

Point 8 sounds rather funny to me: "Fortunately, facelets have good support for this with templating and components."

Don't you realize that Facelets -IS- JSF? Facelets is not a patch or a fix, but something that the JSF spec explicitly made possible in the core design of JSF.
---

henk, just look at the votes ;)

I see, but did you noticed there are a quite a lot of votes there from guys who probably aren't Java programmers at all? I don't know all of them, but if I'm not mistaken someone like docmach is really not a Java programmer. @docmach, why did you voted this article up? Really curious. Naturally this ChendlerBing guy is an abvious fraud too.

I also see very few to almost none of the other dzone regulars who have made interesting comments about Java technology in the past voting the article up. That's at least a bit.. uhm. funny.

Don't get me wrong, I'm open for critic, but just a bunch of votes without any substantial comments isn't that convincing to me really. I hate to use it as an argument, since we're really playing on another level here, but... the nazi party in ww2 got a lot of votes too. It didn't prove though they were doing the right thing...

Henk,

What if I don't want XHTML? And you know, even the future is not XHTML. HTML 5 is already being worked on just in parallel with XHTML.

>What if I don't want XHTML?

Yeah, what about that? There's nothing in the JSF spec that ties you into XHTML. If you want to use HTML 5, use a set of components that output HTML 5. Likewise, if you want to output XUL, use components that output XUL. I'm not sure why this needs to be repeated, but JSF is neutral with respect to both the output (XML, XHTML, HTML5, XUL, etc) and the view description technology (JSP, Facelets, direct in Java, XUL again, etc).

Just to mention that the "Look at the votes" argument is not valid: unfortunately, many DZone users vote a post upon the title/subject (for example, some java guys vote down ruby-related posts on sight, and certainly the opposite is also true :) ) without even reading the thing ...

While some of these points have merit, most of them are outdated FUD. Clearly you have not tapped into the power of Seam. Okay, so I am telling you to add another framework, but on the other hand, yes, we move forward. JSF wasn't perfect by any means. But projects like Seam are taking it in a new direction that arguably makes the combination the best framework choice available.

For instance, you should almost NEVER use the HTTP session scope to store beans. The page scope (from JSF, exposed by Seam) or the conversation scope (Seam) are far more suitable options. Both solve several of the problems you cited. In fact, the back button problem is mostly due to use of the HTTP session. (#4, #5)

Additionally, Seam provides a very elegant way of doing non-POST action requests in JSF using its page-oriented features. A seam-gen created application uses very little form posts, in fact. Combined with URLRewriteFilter, you can even achieve those friendly RESTful URLs. (#6, #7)

I also want to comment on your desire to have complete control the output. If that is what you want, then sure, JSF is not for you. JSF is designed to allow the creation/selection of XHTML, CSS, and JavaScript need for a page to be delegated to the component library in return for greater productivity. If you have a problem with the output generated by RichFaces, then your bone is with RichFaces, not JSF. Even then, you are saying that RichFaces has bugs. Okay, that doesn't mean you have to go off the deep end ranting about it. Offer to fix them or choose another component library. (#1, #2)

With Facelets combined with the Ajax4jsf CDK, I don't understand why you have so much trouble creating custom and composite components. These two technologies definitely reduce most of the pain of this task. I think that RichFaces and ICEFaces both prove the great component libraries can be build. (#3, #8)

If you want great IDE support, you should really be looking at JBossTools. No, it is not just a JBoss thing. Max Anderson has done a phenomenal job taking the old Exadel product to new heights. (#10)

I'm not necessary standing up for JSF here because I really don't have time for a fight over what is really a personal preference. All I am saying is that JSF is a start and frameworks like Seam and the next generation specs are improving on many of the problems you cited.

"Don't you realize that Facelets -IS- JSF? Facelets is not a patch or a fix, but something that the JSF spec explicitly made possible in the core design of JSF."

Yes, finally someone put this into words! Excellent point. Somehow people think that JSP must be used or else you aren't really using JSF. That is so not true. JSP just happens to be the default view handler and really a crappy one at that. Facelets is simply a newer, better view handler that fits much more naturally with JSF. It's a shame it wasn't included as part of the JSF RI because then this point wouldn't even have to be argued.

Wow, what an ignorant piece of FUD. Most of this rant is relates to the author's ignorance between what is JSF and what is extensions ( RichFaces et al. ). The remainder is focused on the author's poor use of the Java language. If you can't figure out how to lazily load your data once without round tripping to the DB every time, I think you need focus more time practicing writing code and less time ranting.

I happen to agree that JSF is a failure, but I disagree with the reasoning.

Your mileage may vary, but at least for us it has been a great success and we're really happy with JSF.

No doubt it has, but EJB2 was extremely popular at one point, even though it was always doomed.

The difference is of course that JSF is not EJB2. I understand this may be hard for you to get, but not everything from Sun is automatically the same as EJB2.

I'll overlook the personal cheap shot, and assume you are interested in a reasonable debate. I did not suggest that everything from Sun was the same as EJB, I simply said JSF looks to be on the same doomed list. Is this so hard to accept as a reasonable opinion?

Fwit I think Sun has mostly got it right, esp with the web stack (servlets,jsp etc - evidenced by the fact that all other frameworks are built on top) but not with JSF.

>I simply said JSF looks to be on the same doomed list. Is this so hard to accept as a reasonable opinion?

Well, if it's just your opinion sure. It's a free country and you are of course allowed to have your own opinion. Personally I don't share that opinion, as you might have understood ;) Also, I see a lot of people saying stuff like: "EJB2 was terrible. EJB2 was from Sun. JSF is from Sun. Thus... JSF is terrible". I'm not saying that you said exactly that, but you must admit that it's a line of reasoning which is often used. My reaction was maybe more a reaction to this, than it was directly to what you said.

>Fwit I think Sun has mostly got it right, esp with the web stack (servlets,jsp etc - evidenced by the fact that all other frameworks are built on top) but not with JSF.

Again I beg to differ. I see a lot of frameworks and other stuff being build on top of JSF. Take for example Seam, Facelets, Trinidad, Orchestra, etc etc. I personally see JSF more as a meta framework than as something that's usable right out of the box, but maybe that's just me. Nevertheless, there are A LOT of extension points in JSF all of which are extremely useful (IMO) to build your own extension or even framework on.

The author (vepetreski) is not really a fair person. I posted on his blog, defending some issues regarding JSF, and he simply removed it. Also here, the only thing he seems able to say is "look at the votes", without providing any substantial defense of his own points when criticized. Any way, just so I had not posted the last reply for nothing, I'll post it here. This was in response to http://www.comesolvego.com/2008/05/03/game-over-java-server-faces/#comment-106

@Peter

>First you agree that JSF was released by Sun without much testing because “Sun just didn’t have the resources”. Wow.

Wow indeed... for your ability to misinterpret my words. Read again:

>>If it were tested then Sun would have built basic functionality into the components that is needed.
>You forget Sun just didn’t have the resources to also create a rich set of components to go with the first release.

Where do I say there that JSF was released without much testing? The core got a huge amount of testing and design verification. So much in fact that there weren't any resources left to also release a high quality component set. This was, as mentioned a couple of times already, deliberately. The platform is open for anyone to create a set of components, but for that to be possible the platform has to be there first. So, Sun created the platform first WITH A LOT OF TESTING and IMO did quite a good job on that.

>Next you say that we should pretend that JSF was released as version 1.0 only in May 11, 2006 when in reality the date is March 11, 2004.

Be serious dude. Read what I wrote: "the first release of JSF in Java EE was actually not before May 11, 2006". That statement is simply true. If you're the kind of shop that primarily uses a Java EE application server and not a lot of external libraries, then yes, JSF as part of Java EE 5 is JSF 1.0 for you. Like I mentioned, Swing was actually available as a standalone package before Java 1.2. Nevertheless, everyone regards the Swing version as introduced with Java 1.2 as the first 'official' one.

>you are advising us to hold on, the best is yet to come [...]
>And then you say yeah, things can be improved and it would be nice to have support for that but hey, not to worry - everything will be fine in JSF version 2.0

Your talent for twisting someone's words is truly amazing. If it weren't for the evidence plainly in sight above this post, you would probably get away with it. Luckily the posts above are still there and largely unedited by the author. As can be clearly seen, I only mentioned that I thought 1 single thing (client side validation) was being considered for JSF 2.0. Yet, you start to make an amazing show out of it claiming that I say to hold on since everything will be fine in 2.0.

To re-iterate, the core of the current version of JSF (1.2) is amazingly powerful today. It was specifically explained how page load events, custom messages and a conversation scope can be utilized -today-. Of course there are going to be improvements in JSF 2.0, and quite a lot to be honest. This is simply a natural thing for a healthy technology; it gets a constant amount of improvements. Whenever there are no such improvements on the radar for the foreseeable future, a technology is said to be dead. Luckily this isn't the case for JSF. There's an incredible vibrant community active on JSF today and there are a lot of improvements and additions on the horizon.

>Guys who are writing such simple UIs are least likely to complain about JSF

Believe me, -those- are the ones who complain. The idea of separating their view code from their control and 'business logic' is simply too much for these guys. If you're building really small web sites I can even agree with them. The right tool for the right job. For a 3 page web site just putting everything directly on the JSP page might be a good approach. If you keep doing that when your application is 200 pages and 200.000 lines of code, you're insane.

@henk. That's stupid of the writer of that article. How many other comments has he deleted? It's easy to make your point if you delete all comments of your critics!

I don't agree with the article at all. JSF is a great technology and we are really productive with it! It's also not at all hard to learn. My business logic is quite simple, but it's really 10x more complicated than JSF. If you think JSF is difficult, how do you write your business code then?