Scott Leberknight's Weblog

After a month hiatus from blogging in which we took a week snowboarding at Whistler/Blackcomb and my time seemed to get sucked down the drain, I've started reading Core JavaServer Faces. Mind you, it is not because I am enthralled with JSF or that I really want to use it on any future projects. I am learning it because I am sure that in the near future I will have to explain to a client why I don't want to use it on a project right now.

I've read a lot of people's opinions on JSF on various places like TheServerSide, SYS-CON, IBM developerWorks, and another one at SYS-CON.

Obviously there's no shortage of opinions both ways. One of the things that annoys me is how JSF was designed for tools. There are some people who I've argued with and others whose articles I read who try to dispel this "myth" and say its not true. Well, it is true. In the preface to Core JSF, David Geary explains the JSF "framework was designed for tool support". Not designed with tools in mind, not designed so tool vendors can provide tooling, but designed purposely and specifically for tools. Now I am not against tools per se; in fact I use them all day long every day, e.g. IDEs, build tools, test tools, etc. But I am little skeptical of a framework designed and targeted for tools. Since David is a member of the JSF expert committee, and because I have now heard him say that in person and now in print, I believe it.

Yes, you can build JSF application by hand in vi if you like, but since JSF was designed for tools, it would be common sense to think that using a tool to build JSF applications would make it easier. One of the great things about the Java and open source worlds is that most things are first designed and used by people hand-coding everything, and then tools are built to support things that are tedious and repetitive. JSF inverts this by beginning with tools. Therefore from what I have seen (I'm only a 100 pages into the 600 pages of Core JSF) the JSF expert committee wasn't really too worried about those people who actually are more productive hand-coding or are experts and therefore can be slowed down by some tools.

Another thing about JSF is that it seems to force developers to build JSF applications, not HTML-based web applications or any other view technology. In other words, JSF strives to be completely agnostic of the specific view technology. That is fine in principle and might even work itself out to be a good choice, but for now it seems you have almost zero control over the HTML generated in your web application. Contrast the JSF style with all custom JSF tags with Spring which completely separates the view from the controller in its MVC framework, and does so with a minimal amount of coding and intrusion. It was designed for different view technologies to be plugged into the web framework, and actually supports multiple view technologies out of the box - JSP/JSTL, Velocity, Freemarker, XSLT, PDF, and Excel to name some. JSF on the other hand supports only JSP out of the box as a view technology. It seems that JSF pages are a morass of custom JSF tags, with very little HTML at all. Thus without a tool that explicitly supports JSF, a web developer who only knows things like HTML, CSS, graphics, etc. is going to have a tough time! In addition, this model makes it hard to customize the generated HTML since it is generated for you.

Having been to JavaOne the past two years where Sun has repeated how they want to make Java/J2EE development easier and lure masses of Visual Basic developers to Java. A noble goal but it could backfire if it actually succeeds. I say "backfire" because that means the Java world would all of a sudden have a group of developers who can use a tool, but have no idea what's going on underneath. That is always a recipe for problems, because there always are unique problems you run into during every single project you work on., and which require a deeper level of understanding than someone who only understands how to point-and-click. Anyway, I digress.

The point is I will get through Core JSF, building the sample applications by hand in Eclipse and UltraEdit, and perhaps I'll later blog about how I was wrong. But right now I'm not counting on that outcome; we'll see what happens. Perhaps as I go further with JSF I'll change my mind. Most times my first impression has been about right, but I definitely have misjudged things before. The worst one was my initial impression of Spring. After the first article I read, I wasn't really interested. But now I am a huge Spring user and advocate.