Java Development News:

Rethinking JSF - The Real Problem

By Joseph Ottinger

01 Apr 2007 | TheServerSide.com

JSF - JavaServer Faces, JCP's component framework for the presentation layer - has had a long and fairly controversial road so far. There's still a lot of dislike floating around for it, as you can see on various TheServerSide threads that deal with it head on.

The problem isn't JSF - not for the most part, at least. The real problem is the perception of JSF, as well as how it's being shown and taught.

JSF is, as stated and well known, a component framework. Let's look at the components it has: a text input of various sorts (hidden, text area, single field); buttons; radio groups and check boxes; links, anchors, data tables, even simple grids.

Of these, while all are necessary for decent user interfaces, only the tables even come close to being anything like a unique or useful component. Even the dataTable falls short, in the reference implementation, and the other components rest are simply necessities.

The real problem is that JSF, for a component framework, has so few components.

What kind of component would be useful? Well, consider your standard web application and how a user interacts with it: the user logs on, looks for something, reads it, possibly creates something new, then logs out.

So... where are the login box components? Where are the search box components? Where are the data input components? Where's the ability to manage "pretty URLs?" ("Pretty URLs" are also known as bookmarkable URLs, or search-engine-friendly URLs.) Where is the data flow? Where's the conversational state?

There's absolutely nothing in JSF that prevents these things from being made, and some groups (vendors, open source groups) have already made some of them - frameworks and implementations like Seam, IceFaces, RichFaces, Tomahawk, NetAdvantage, and others. For others, code is readily available in books like "JSF: The Complete Reference" (Schalk, Burns), "JSF In Action" (Mann), and "Core JSF" (Geary). Some elements are even available on the web (for example, how to manage pretty URLs). There are also sites with lots of JSF information: IBM developerWorks, Java.sun.com, www.jsfcentral.com, www.jsftutorials.net, and TheServerSide itself.

Most of these sites and references use JSF as it's meant to be used: there are no servlet filters (well, except in a few cases, where it makes the most sense). There are no servlets. All of them use the JSF component lifecycle, all of them are portable between compliant implementations of JSF.

But most of the documentation focuses on the inputText component and its near cousins. While navigation and data input/output are, well, extremely important, by focusing on these, all JSF mentors are doing is telling people how JSF is different from what they're already used to. It's hard not to sympathize; authors tend to want to show simpler mechanisms to show something useful, rather than presenting something that needs advanced knowledge. If they opt to show something that needs advanced knowledge, then they alienate the readers who don't have it.

People don't normally like change for the sake of change. They need a compelling reason to change. People have budgets and timelines to deal with. Learning a new XML configuration and component lifecycle... these aren't compelling reasons to use JSF, they're compelling reasons to use what you already know.

Considering the material that's already out there... even the simple components used are a problem. Consider the two following text input fields:

<input type="text" name="foo" value="$foo" />

<h:inputText id="foo" value="#{backingBean.foo}" />

These are potentially equivalent. (Well, on the surface; the latter has a lot of capabilities that aren't obvious on the surface.) There's a lot that goes on behind the scenes in the second one, but it uses a custom namespace, a more complex expression, and two new attributes despite being (supposedly) a map directly to the simple HTML equivalent (which, in this case, uses a Velocity-like syntax for including a default value).

But regardless of their function, it's got all these new things - and for better or for worse, people prefer what they know, what they expect to see. (As a famous American General said: "Never change a winning team.") Your standard developer toolkit normally includes Java on the server side, and HTML and JavaScript in the client side stuff... and now JSF wants to add even more, by having its own special HTML tags.

The result is that a lot of people are left with a bad taste from the very start. Why use <h:inputText /> if <input /> is what's familiar, and what <h:inputText /> ends up being in the end anyway?

People tend not to pick up the compelling reasons here, because they're not very obvious. <h:inputText /> can be very powerful, and its AJAX-enabled cousins even more so, but this isn't something you notice without a presumption that there's something to see. Navigation is fine, JSF's not underpowered in that area (especially considering that you can replace the navigation mechanisms should you choose to do so); the expression language is becoming more standard over time (and it, too, is pluggable; I routinely use Spring2 to resolve variable references in JSF, for example.)

The real problem is that the existing standard components are simply too basic to offer any real benefit to users, and creating new components is too much of a jump from using basic JSF features. The curve there isn't impossible, but it's steep enough that people resist it.

This isn't good for JSF.

Now, you might have noticed that the reference was to "existing standard components." That's entirely intentional. As stated, there are some existing component frameworks that offer some interesting, useful, and (in some cases) amazing variants of the standard components as well as some fairly necessary extensions like date and time selection widgets, rich text areas, spinners, and others. That said, there's one company that deserves praise for actually pushing JSF in the right direction: Oracle.

ADF Faces is a fantastic set of widgets with drop-in functionality. Need a wiki? Drop in the wiki JSF component. Need a forum? Add the forum JSF component. This is the kind of component JSF was meant to enable, and when you think of the power of combining a JSF page with a portal's drop-in functionality, then you begin to see the sort of composition that leverages JSF.

On TheServerSide, for example, imagine the ability to create a JSF component for each content section. Stick that component into a tab panel (available through many JSF implementations today), and add an ADF discussion forum to each topic in the content section, as well as (perhaps) a wiki component to allow free-form linking and commentary... and you have something. This is entirely possible without JSF, of course, but JSF's ability to drop in capabilities without custom coding is enticing.

With a proper component set, then, the problem isn't JSF itself. It's the ecosystem around JSF. An ecosystem is fairly easy to fix: all it needs is a certain critical mass. Enough users and the ecosystem will grow, if it can.

There is somewhat of an ecosystem already, of course In addition to the component vendors, there are a number of tools for JSF developers: JbossTools (previously Exadel Studio), BEA Workshop (a merge between Workshop and NitroX' M7 product), Jdeveloper from Oracle, Instantiations has some excellent Eclipse plugins, Genuitec can't go without mention of MyEclipse... NetBeans has a lot of JSF support, IBM has some nice JSF tools, and IDEA has JSF support as well.

So tooling support is already out there. There's some who say that JSF was made for and by the tool vendors (using the same logic as those who use Torx bolts: if you use a Torx bolt, you have to use the star-shaped Torx wrench.) This is a little unfair. The tools exist to make migration to JSF easier for neophytes. Experienced developers get the benefit of some of their features, but by and large, the tools don't replace experience, the way some other RAD tools attempt to.

Using the same reasoning behind some developers suggesting that the ideal IDE for Java beginners is notepad or vim and a command line, it might be that the tools remove some need for JSF knowledge. This can certainly create the illusion of core competency before it's actually present, and it's fairly easy for such JSF developers to get confused.

Does that remove the need for JSF IDEs? Of course not. Just because you have a tool that makes initial exploration easier doesn't mean that the tools are flawed, or the framework is flawed. The failure of the JSF IDEs to create a wave of new JSF users mostly shows that the JSF ecosystem does a poor job of explaining itself to JSF newbies.

The ecosystem presents all of the capabilities and power without explaining the core ideas, without explaining to users what they actually need to know first, and without really explaining its real benefits in terms that differentiate it from the other component frameworks.

The real problem is that with such basic components in the reference implementation, JSF really has no true benefit until users investigate and invest in better components. Users won't find better component sets until they see the potential in using JSF in the first place, and the documentation doesn't make this point up front, in clear and emphatic language, enough such that users "stick it out" until they learn JSF to the point that it yields the real benefits of its component model.

The bottom line is that JSF is an extremely capable component framework. It certainly isn't the only component framework out there, and it's not this article's point to contrast and compare any of them. For better or for worse, though, JSF is part of Java EE, and it's at worst a necessary evil, just like JSP is - you can work around it, but it's going to be there whether you like it or not.

JSF is simply too good to treat that way. It's on par with any other framework out there and the impact of it being a standard means that users and implementors have a level playing field - you know how JSF is supposed to work, and if it's compliant with the specification, you know it works. If it doesn't, you can switch it out.

The real problems JSF has are serious. They're not show-stoppers; they can be fixed, and they're being fixed. There are better component sets out there already, some of which provide the components and backing models that JSF was designed to enable. Facelets replaces the JSP presentation mechanism with something much faster and much cleaner (in your Humble Author's opinion). The formation of the JSF 2.0 expert group is designed to bring the benefits of Java EE's simpler model to JSF. The documentation is constantly being revised, and with new books on JSF on the shelf (not even counting the books focusing on Jboss' excellent Seam project, which uses JSF), the documentation will soon reach a tipping point where JSF becomes more accessible.

When that happens, look out.

Advice for new component authors: stop reinventing the wheel! Everyone has a tab panel, a menu component, a spinner, a drag-and-drop mechanism. It's been done. While perhaps newer and better ways to do things will always be welcomed, aiming for a "me-too" implementation doesn't help propagate the technology in any real way. What JSF needs is a set of components that use interfaces as models, along with a "standard implementation" of those interfaces that can be replaced at runtime with specific functionality. Along with this set of components, documentation that addresses the learning curve would be welcomed.

The state of the art in JSF is advancing rapidly. The books mentioned are excellent resources, and many of the Seam books offer rapid and useful introductions to JSF (as well as EJB as a backing bean mechanism.) This isn't the time to rest on laurels, though. JSF has the advantage of being a standard, but being a standard isn't enough; a standard that doesn't do what people need can, will, and should be replaced. JSF doesn't deserve that, in your Author's opinion, but the developers make the real decisions.