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