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.
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.
