This is the final part of my three-part series on why JSF isn’t my personal choice for future development work. I focus on the woes of the doing HTML interfaces in JSF.
Download JSF Part 3.
The major problems I speak to:
- The HTML put out by today’s JSF components is neither standards compliant or semantically meaningful. Take a look around the web, and you’ll see all sorts of movements that require good, semantic, standards compliant HTML. JSF’s rederings are stuck in 1999.
- The HTML for the components is very far away from the page layout (it’s in the RenderKit). To fix HTML problems, programmers will likely find workarounds instead of fixing the problem. That’s a set of Broken Windows waiting to happen (see The Pragmatic Programmer) . It doesn’t encourage the kind of clean programming that I think it ought to.
- RenderKits are an artifact of the Architecture Astronauts. They are so unlikely to be used for the purpose for which they were designed that they create more pain than solution. (Will all seven of you using your JSF for HTML and WML please stand up?)
- Finally, JSF turns JSP almost, if not entirely, into a data language (or declarative language) instead of an imperative language. The page layout is used to configure the component tree, and has no direct representation of executable statements like “if” and “for”. Some view this as a triumph; I think it’s a tragedy.
Again, I’d rather be solving the business problems than finding workarounds to these restrictions and annoyances of JSF. If you’re interested in reading and hearing more, please see my previous posts here, here and here.
UPDATE: The mp3 file should now be in the right spot. Serves me right for posting in a rush. Sorry. While I’m at it, I might as well claim my Odeo channel (odeo/0f55e88149deb27e). Enjoy.
In part two of my series of podcasts on why I’m not interested in using JSF in the future, I focus on the Leaky Abstraction that it provides. I feel like the leaks get in the way of getting actual work done; they confuse new developers, and cause headaches for everyone. Users even see the results of the leaking.
Download JSF Part 2.
Some of the leaks I discuss include:
- Ultimately, JSF provides a Leaky Abstraction that (in spite of its promise) still requires all developers to understand Request-Response in addition to the 6 lifecycle phases.
- Security in the web.xml is based around URL, and by definition you don’t know the URL for many JSF actions. This makes it MUCH harder to get the fine-grained security right, but also expose the basic servlet (think Request-Response) nature of the application.
- Users may refresh a page, like the Search Results, and be whirled away to the search entry page – their results having been scattered to the wind.
My point isn’t that these items can’t be dealt with, but that the core abstraction leaks somewhat and I prefer to do without it. I have many choices of Java web frameworks. I’d rather be solving the business problems – those are by far more important. Please see previous posts here and here.
UPDATE:The third and final part of the series is now posted.
Yesterday’s JSF podcast seems to have kicked up a bunch of responses. Many new visitors aren’t familiar with my typical podcast format that splits a topic across two or three shows, so the comments have focused around the one item I brought up so far. Below is an incomplete list of problems I intend to discuss in future episodes; it’s rough and intentionally not cleanly edited yet. I’d rather save the detail for the podcasts, but for what it’s worth, here’s my list. Also note that this is my list of things that added together created my personal opinion (I obviously don’t speak for my employer or any of the other 25 developers on site) to avoid JSF in the future, and that I don’t claim to be an expert. Also bear in mind that many of our approaches were set in the summer of 2005, and I’ll bet things have evolved since then. I’m sure workarounds exist, but I’d rather move on to solving the business problems of my employer.
I assume that astute readers and listeners will go away and be responsible for their own conclusions. I expect that people also understand that many choices like this are highly dependent on your environment, your staff, your goals, and you general approach to development; and all the people I’ve worked with have been responsible in their considerations of such things.
I pretend no prophesy of doom and gloom for JSF, on the contrary I believe many people will continue to use it well into the future. I just won’t desire to be one. I don’t even care to actively discourage anyone from using JSF. Do What Make Sense — it’s your code. So, for those of you left that care to see a rough sketch of my coming podcast episodes, there you go:
- 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]
- Component writing is much more difficult than writing JSP tags (Rick Hightower convinced me of this at NFJS)
- Small free component market (compared to Eclipse; probably side effect of #3) [or even delphi components]
- Security in the web.xml is based around URL, and by definition you don’t know the URL for many JSF actions. This makes it MUCH harder to get the fine-grained security right. The books and documentation we found glossed over that and recommended we abandon containter managed security and write our own. (What’s the point of JAAS and all the other security advances made if we’re advised to “throw them out”?)
- Unit testing our pages is too difficult. We’ve basically had to give up unit testing our pages. Our short experience with Spring MVC was nice in this area — it had mocks for most of the stuff we needed to make our tests easy.
- The HTML generated by MyFaces ignores web standards [uses tables for layout] and is generally ugly (obviously subjective). Doesn’t have clear support for accessibility (a big co-movement with web standards). Why are we back in 1999 again?
- We hired a graphic artist, but had to throw out and rework large portions of her web standards compliant design once we saw the actual HTML rendered by MyFaces. The look was noticeably compromised.
- The RenderKit distances the HTML far from the page definition, and makes editing it prohibitively difficult. Looks like the designers (didn’t optimize for the common case (HTML) and missed out on reading the Information Architecture and Web Standards community stuff. Otherwise they’d know how important it is to develop a semantically meaninful HTML structure based on your site’s content. They’d have realized that this means that nearly everyone should conciously design their HTML. Instead they made this important step MUCH harder. [read this, and substitute the concept of rendering for messaging]
- The client side validation available from our components isn’t sufficient.
- Existing JSP tags are difficult or impossible to use.[this may just be our experience we haven’t spent a lot of time on it- but trying to integrate normal web cycles into the jsf lifecycle has been difficult]
Their existence is now just salt in a wound. There are many hundreds of JSP tags, and among them are a few really good ones. We’ve made several attempts to integrate various tag libraries, but none of them have proven worth the effort.
- Since JSP’s no longer hold HTML, it’s much more difficult to look at a page definition and understand what’s going on. Good tool support here is essential, but sorely lacking or prohibitively expensive.
- Templating seemed difficult to do with JSF [our difficulty using sitemesh may have been due to our design choices, but at the time others were reporting difficulty as well]. In the end, we (like many others) still use Tiles which is decidedly Request-Response oriented.
- Ultimately, JSF provides a Leaky Abstraction that (in spite of its promise) still requires all developers to understand Request-Response in addition to the
7-layer 6-layer lifecycle. (“Response already committed” error, anyone?)
- The popular implementations are still maturing in many ways. (Can I get some words in my documetation? I’m accustomed to more.)
- You can’t display a collection or map in a drop down – must first convert to another object. That’s really annoying. Why didn’t they use jstl?
- There is no (free) full blown Eclipse editor. That actually might be the last ditch option for jsf to gain some kind of momentum. I’ve heard Oracle’s JDeveloper is free, but I don’t know if it’s worth switching.
NOTE: Comments are currently broken. I’ve recently moved servers, and my new one is missing some libraries needed. I hope to have it up soon.
Our team has used JSF for the better part of a year. My vote: skip it. Check out the first of a long list of reasons why the JSF 7-layer burrito won’t be on my round for seconds.
In this podcast, I stick close to our experiences with JSF as a team, and my opinions on it. If you’d like to read stuff others have read about it, a couple searches should put you smack in the middle of a debate.
If you’re looking for information on the REST architecture I talked about in the podcast, you can get the short version from a third party, or the original dissertation from Roy Fielding.
Download JSF Part 1.
UPDATE: This page has been read more than twice my average (though the number of podcast downloads are still normal — is anyone new actually listening?). In anticipation of more podcast episodes to come, I’ve posted a more complete list of the things that made be decide I’d like to avoid JSF in the future.
UPDATE 2: Part two of the series is now posted.
FINAL UPDATE:The third and final part of the series is now posted.
This was a wonderous site to see, and one a long time coming. After long months of working to build a sense of importance for the build, we finally got every one of our 199 projects in CruiseControl to build successfully. Good work team.
One obstacle we faced along the way was knowing exactly how many of our projects were failing. That’s what lead me to submit this patch to CruiseControl. It was accepted and has since been improved upon by others, I believe. It’s finally nice to see the “Failed” count down to 0.