JSF is a diamond in the rough, you just need to make it shine
PDFJSF is hard to learn yes, but in my opinion it doesn’t suck as bad as Wille says. All the points Wille mentions can be solved by certain libraries or write-once reusable solutions (I’ve included my ‘magical’ combination of frameworks on the bottom). JSF is a diamond in the rough, you just need to make it shine.
Contents
The devil is in the details
There are a couple of pitfalls you need to know about with JSF. It’s all really a matter of having read a good book about JSF that points them out, or having learned them the hard way. Luckily I’ve had some guidance by experienced colleagues of mine; I’m guessing that’s the missing factor in Wille’s situation.
Referring to the pitfalls you need to know about, I’m talking about the common beginner’s problems like using JSTL c:tags that cause havoc when combined with those of jsf and facelets. I’m talking about the Ajax4Jsf details as Wille mentioned: once you know what to use it’s easy. Those 48 attributes? most of them are inherited and never used and you can forget about them, and that’s the learning curve. Once you know the right ones, it’s using exactly those, over and over again. And things like how you can incorporate Spring security and stuff like that. Another pitfall that comes to mind is how action=”” work quirky with navigation rules when using the array notation (action=”controller[‘action’]”). And ofcourse there’s the issue of parameterized JSF validators, which needs some understanding. All pitfalls that can baffle a beginner or intermediate.
The thing with JSF is there are a number of little things that are hard to solve, but once you’re past that it does make you much more productive. You just have to have a solid base to start from each project. The pitfalls learning curve is definitely a downside of JSF, but JSF 2.0 is in the making to solve all these issues.
Bad performance or beginner’s mistake?
Then there is this performance issue Wille mentions, where I think he missed the target: JSF does not have to be slow at all. It really depends on how you treat your backing beans. JSF has the weird tendency to call setters/getters multiple times, which seems utterly pointless (it’s related to resolving valuebindings in nested components). I’ve made the mistake before to directly retrieve values from a controller/service in my views instead of a static model (backing bean): this is what makes things slow. JSF in itself isn’t that slow for a webapp: yes there are many redundant calls but we’re not dealing with a realtime simulation application, webapps do just fine. On a sidenote, it also depends on the implementation… JSF is a reference specification, while there are various implementations of the framework (IBM’s, Sun’s etc.)
SEO friendly JSF?
Ahh, but for the JSF Search Engine Friendliness. That’s solved too, somewhat. There’s is a framework called PrettyFaces which allows you to dynamically generate/interpret pretty GET urls with bean values. It’s a great framework that solves a common problem, but there still exists the problem that existing jsf/facelets/richfaces components are not generating SEO HTML code. That’s really the fault of the component makers, not JSF, though JSF definitely isn’t innocent with its POST obsession: PrettyFaces fixes at least that.
Common sense: use frameworks to avoid most pitfalls
Once you’ve got those kind of things down and use a good framework combo, JSF is straightforward. You won’t really need to know about the various phases and you can be very productive if you’ve set up the jsf/facelets components right. I’ve worked with JSF intensively for about a year now in various projects with various implementations and I hardly ever need to use phaselisteners and that sort of stuff. The rare cases where you do need them, you can define these things ones and reuse them in other projects. With this approach I’ve created a template project with some standard libraries, phaselisteners, security set up, facelets components etc. and I’m up and running in no time.
I haven’t sanitized or otherwise cleaned up the template project so I won’t put that up for the time being, but at least I can tell you what frameworks are in it by default.
- The magical combination that works for me and my colleagues:
- JSF (MVC)
- Facelets (Templating, use of XHTML)
- Richfaces (component suite)
- Richfaces A4J (Ajax support)
- Tomahawk (only for file uploads with the Extensions Filter)
- PrettyFaces (for indexable GET urls)
Now that I’ve mentioned these, you should check out JBoss Seam as well, which basically is supposed to do everything the above libraries do combined, plus a couple of things more like solving the conversational scope issue. I haven’t worked with this framework myself though so I can’t speak from experience.
Final note
Although I agree JSF has some annoying pitfalls, shortcomings and a high learning curve, it’s been out there for enough time to pass for supplement frameworks to pop up from under the ground to solve most of these problems.
With the right combination, most classic counter arguments have become obsolete. Maybe it’s time for critics to take JSF as is: incomplete but ultimately making you more productive if combined with the right frameworks.
Tags: a4j • facelets • java • JSF • PrettyFaces • richfaces • seam • tomahawk
Lincoln
Nice article, benny! Great description of the power of JSF extensions and frameworks. JSF is a base framework without too many fancy frills, but there are a lot of extensions out there to make it kick total be–hind!
SuperDude
Ha, deleting comments we don’t like are we ? Just google “JSF sucks”
have a good day 🙂
Benny Bottema Post author
Actually no, I’m deleting propaganda. You did not go into any details of my blogpost; I suspect you didn’t bother to read it all. You did however just spam a link here to a nonobjective biased site of propaganda, which doesn’t give a balanced view of the technology at all. You said you wanted people to decide for themselves? Then don’t poison their pool of information.
Also, to refer to your actual remark: try searching “God sucks”. The results are obvious, yet at more than half of the world seems to like Him. It doesn’t prove anything, except JSF isn’t for everybody.
If you want to discuss anything, go for it. If you just want to hit and run, you’re in the wrong place. Stop acting like a child.
have a good day 🙂
PS. For the curious, here’s the link to referred site: http://ptrthomas.wordpress.com/2009/05/15/jsf-sucks/
SuperDude
Taking your wonderful argument a little further:
It is obvious that JSF sucks, but a significant portion of the Java community (including yourself) seem to like it 🙂
Anyway, the fact that you dismiss as “propaganda” – a comprehensive list of hyper-linked, verifiable references to comments by real people, including names such as Matt Raible, Bob Lee, Rod Johnson, Sanjiv Jivan etc. – that speaks for itself. I’m wondering whether _you_ bothered to read it all.
Benny Bottema Post author
You argument is flawed. I never claimed JSF sucks or doesn’t suck. I’m claiming it can make you productive given the right set of tools. Also, I implied you can’t determine JSF suckiness by Google page counts, which you keep insisting on.
Concerning your doubts whether I read it any of it: I have, it’s an old thread and I’ve participated in the comments thread as well. The reactions (to everyone’s in fact): single minded flaming. No adult arguing, just simply flaming with one goal.
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.
SuperDude
Let’s just step back a moment.
1) you admit to deleting a comment, the lowest form of blog etiquette. then you lecture others on “discussing” and “acting like a child”. nice.
2) I mentioned googling for JSF sucks once. you say “keep insisting on”. liar.
3) the good thing about the list of links is that it starts from 2004 but continues upto 2009 / the present (5 years of suckiness!). of course, you have to bash the one link from 2004 saying it is out of date. nice try 🙂
This pathological behavior is something I’ve observed in a lot of JSF supporters – people who have invested a lot of time in JSF, who have not investigated the alternatives and who don’t have the strength to admit it. It’s cognitive dissonance.
Benny Bottema Post author
Sigh. I won’t let this flaming go on for much longer.
1). There are several valid motivations to delete a comment. Your first comment was compatible with my definition of spam. If you look at some other comments on my posts, you’ll see I’m not one for deleting comments I don’t agree with. Stop acting like a child still.
2). This is getting a bit immature, but I’ll indulge you. You referred to ‘googling JSF’ once, then I countered it by showing it’s pointless, to which you replied by turning that around to support your first claim. At least that’s how I understood it. Sorry if I misunderstood.
3). I just picked the first name that stood out to me from the list you used for your argument. Way to go brains. Let’s just go over the entire list then, shall we?
Rod Johnson: 5 years old dinosaur post on JSF alone.
Bob Lee: three years old post, comparing JSF alone to Google Web Toolkit. He works at Google himself.
Matt Raible (reference 1): 5 years old dinosaur post on JSF alone.
Matt Raible (reference 2): 2 years old post about how JSF sucks without suplemental frameworks such as Facelets. Completely supports my claims.
Matt Raible (reference 3): Matt mentions a different blogpost by Xebia about their experiences with JSF. They didn’t even use Facelets; ofcourse they’re going to have a hard time developing with JSF.
Sanjiv Jivan: Reasonably recent post witth an assessment on JSF alone, and then Flex and Ajax. Again no mention of supplemental frameworks. I also respectfully disagree with his view on Flex. The company I work for has proven otherwise to me on every facet, including SEO.
I agree with most of these guys, but their arguments are mostly irrelevant, as they only cover JSF on its own: that’s pointless. That’s like saying a BMW isn’t as safe as an Opel with Airbags, while the airbags are optional for the BMW and you simply neglect to mention that. It’s not how the real world works. Maybe that line of thought worked 5 years ago for JSF, but now it’s exactly as I said before:
Accusing me of displaying pathological behavior only asserts your own. Resorting to character assassination displays a lack of quality arguments on your behalf. On a final note: ‘who don’t have the strength to admit it‘. And what is ‘it’ exactly? you’ve completely failed to define what ‘it’ is that I’m not admitting to. That JSF sucks? I already said JSF sucks on its own over and over, which is kind the the point of this entire blogpost, isn’t it?
SuperDude
>> And what is ‘it’ exactly? you’ve completely failed to define what ‘it’ is that I’m not admitting to.
Let me quote my comment:
>> who have not investigated the alternatives and who don’t have the strength to admit it.
I rest my case.
P.S: Look up “cognitive dissonance” on Wikipedia.
Benny Bottema Post author
Haha, you made me chuckle there. Not because you fail to realize people may actually already know what cognitive dissonance means (and it’s not even my native language), but because you assume I haven’t looked at alternative frameworks. That while you obviously haven’t actually read any of the articles who’s authors you are oh so eager to name. You just jacked the names and yell: “Hey look! I don’t know what they’re saying, but even these esteemed gentlemen agree with me!”. Good thing you rest your case though 😉
Tadili Saad
The problem I had when trying JSF is the lack of documentation for a beginner (I read the core jsf book and it was bad). The learning curve seems to be high but I’m pretty sure that if there was a good book people would start using JSF. Being a sun specification I’m astonished to find that there are so few books on JSF 1.2 (2 books)
Greg B.
Totally agree with Benny on the whole idea on how JSF sucks by its own, it really does. That is why we have number of different libraries and frameworks to use that address this issues. Power of JSF is that it provides us with possibility of mixing and matching different components to our liking, also let’s not forget about that if I don’t like how something works in JSF I can always change it, this is the true power of this framework. Take for example Seam or PrimeFaces they are build on top of JSF to provide a very nice and robust frameworks.
Just my 2 cents
Avri Lev
very nice blog. JSF are diamonds in the rough and http://www.verifiedbuy.com are diamonds in polished
Benny Bottema Post author
Your spam made me smile, which is why it’s still there… 😉
Brian Knoblauch
I’ve come to really like JSF (2.0). It took me a good several months of struggling with it to “get it”, but once I got it, it’s magic. I’ve used several other frameworks before and found them all too overbearing. JSF offers the freedom to do things the way I want, without being so unstructured as to devolve into chaos. A very nice tool for the Enterprise development toolbag!
Ken Hardy
“There’s is a framework called PrettyFaces which allows you to dynamically generate/interpret pretty GET urls with bean values.”
I’m not a JSF expert by any means, but I have a friend who is and he’s in the process of implementing it for his local state government on a department web project. I do know a bit about SEO and your recommendation of PrettyFaces is spot on, it’s a big help for some of the headaches I’ve run across while assisting him with a few bumps in the road with the HTML. Great post, thanks.