Welcome!

Java Authors: Roger Strukhoff, Pat Romanski, Elizabeth White, Mark Cravotta, Liz McMillan

Related Topics: Java

Java: Article

Java Opinions: Geary vs Raible on JavaServer Faces (JSF)

Java Opinions: Geary vs Raible on JavaServer Faces (JSF)

"Whatever you do, don't use JSF. Not yet anyway." Those were the closing words of a devastating blog recently called "My JSF Experience" by J2EE consultant Matt Raible. "JSF is a technology that's likely to succeed," Raible added later - but his main beef with JavaServer Faces was clear: "Plain and simple, it does not simplify Web development."

This spurred the following spirited response from a member of the JSF Expert Group, David Geary. ("I do not speak for the group" when making these comments, Geary notes.)

David Geary writes: 

"Matt starts out by saying:

Of all the MVC Frameworks I've developed with in the last few weeks (Struts, Spring MVC, WebWork and Tapestry) - JSF was by far the worst. And it's not the implementations that are the problem, it's the spec itself (as far as I can tell). Plain and simple, it does not simplify Web development.

Ouch! I don't know what Matt thinks is problematic in the spec, because that's the last time he mentions it in his post. The list of complaints that follow in Matt's article refer to implementation-specific details of Sun's RI and MyFaces and some other things such as lack of JSF support, but nothing about the spec. So I'm not sure how to respond to that.

Also, I don't think that one of JSF's top priorities is to simplify Web development. Certainly that's a laudable goal, but you have to understand that JSF is: Web App Framework + Components + Event Model. That makes it considerably more complex than Struts, for instance, which is simply a framework. Also, JSF was designed primarily for use with tools, although I don't think that coding JSF apps by hand is necessarily more difficult than other frameworks of similar complexity (for instance, Tapestry). I'm sure Howard Lewis-Ship would take exception to that last assumption, but I think it's a pretty accurate statement.

Before I address Matt's specific complaints, let me say two things. First, JSF is not perfect and the Expert Group is well aware of its shortcomings, which we're working on for the next version. Remember, JSF is 1.0 (1.1 actually, but 1.1 is just a bug-fix release); I think Matt would've had a much different perception of JSF if he'd compared it against the 1.0 versions of Struts, Tapestry, etc.

Second, I'm not sure that spending a few days implementing a simple application in each framework is really enough to allow someone to recommend one framework over another. That said, I do think there is some value in such a comparison, but it's not the best vehicle for recommending one framework over another.

Now I'll address Matt's specific complaints:

MyFaces handles duplicate posts nicely. If you hit "reload" on your browser after saving a record, you get presented with an empty form rather than a duplicate record. I believe I got a duplicate record with Sun's RI.

The JSF RI is not very good at handling duplicate posts. It's something we're working on for 1.2.

The ability to specify an "action" attribute on a button (or a link) and them map that action to a page (in faces-config.xml) is pretty cool.

Yes it is!

Every button or link clicked results in a form post. That's just wrong - why can't I have true links like the web is supposed to? So much for bookmarks.

You can have true links: see the h:outputLink tag. For buttons, you can do <h:commandButton type="button"/>, which will give you a push button, not a submit button.

Saving state on the client results in enormously long URLs and/or hidden fields.

That's an implementation-specific detail of the RI (and perhaps MyFaces). The spec itself doesn't specify exactly how client-side state saving needs to be implemented. Also, remember that state saving is pluggable in JSF. If you don't like the way it works with your framework, you can plug in your own implementation.

JSF support is fairly non-existent. Unlike the other MVC frameworks, the MyFaces mailing list has hardly any traffic and the Sun forums aren't much better.

I can't speak for the MyFaces mailing list, but the JSF forum at Sun is quite active. See http://forum.java.sun.com/forum.jsp?forum=427.

I did find some CRUD examples, like this this one, but was disappointed to find that i18n is not considered for setting success messages. I ended up using the solution described in this post. 6 lines of code to set a success message - you've got to be kidding me! Most frameworks have a simple 1-2 liner.

This is the result of two competing forces when designing frameworks: the desire to provide the kitchen sink and the desire to provide a simple API. You can't have both, and this is one area where we deliberately chose to leave out functionality. In fact, you will find other cases (like accessing request parameters) that may seem to be more work than is necessary. I would suggest that you encapsulate those 6 lines in a utility class of your own, which reduces it to one line going forward. Of course, the cost of those 6 lines lies in figuring out how to do it in the first place. You can obviate that need by using good utility classes that someone else has already written. You can find such classes at http://www.corejsf.com.

Waiting for JSPs to compile the first time has surprisingly become painful after using Tapestry, Velocity and FreeMarker for the last 2 weeks.

JSF desperately needs to support an alternative display technology besides JSP out of the box. In fact, it's much uglier than simply having to wait for JSP pages to compile. See Hans Bergsten's article "Improving JSF by dumping JSP" at onjava.com.

Validation messages are ugly. For instance, when a required field isn't filled in, I get: "lastName": Value is required. I was able to override the default messages, but I was never able to use the label of the field (vs. the field's id).

The standard messages are indeed ugly, but it's a cinch to replace them. You should be able to use the field's label.

The <h:messages> tag is practically worthless. Sure it's great for displaying messages (error and success), but that's about it. It has a "layout" attribute that doesn't even work in Sun's RI, and in MyFaces it just wraps a <span> with a <ul><li> or a <table>. Both of these layouts are useless b/c you can't set a css class on them. I ended up using "table" and having to set a generic CSS rule (width: 100%) in order to get the message/error bar to show across the top of my page. This tag also doesn't allow you to escape HTML.

The h:messages tag could certainly be improved, but the layout attribute does work in Sun's RI and you can set a CSS class on them. See the end of chapter 4 in Core JSF. (I'm convinced that Matt needs a good JSF book!)

The h:dataTable component is nothing like the displaytag. MyFaces claims to have a pageable/sortable component, but it requires custom logic/methods in your managed-bean. Yuck. I ended up using <h:dataTable>, which has neither sorting or paging. This is only because I couldn't get an <h:commandLink> working inside a displaytag column.

h:dataTable could definitely use some attention.

JSF-created apps are pretty much untestable. Managed-beans are testable, but the UI seems really difficult with jWebUnit and Canoo's WebTest. IMO, it should be possible to specify a URL to edit a record (i.e. editUser.html?id=2). With JSF and my master/detail app, the link to edit actually sets about 5 hidden form fields with JavaScript and then submits the form. I could probably figure the URL out, but it'd be ugly. Also, the MyFaces h:dataTable will not render an "id" attribute if you specify one. This is needed to verify tables and their data with jWebUnit.

Testability is another area that could use some improvement. At least actions can be implemented in POJOs (unlike Struts), which means that you can test business logic with JUnit.

Finally, Matt mentions that he felt like he was banging his head against the wall with both Tapestry and JSF. I would assert that trying to come up to speed with any framework in a couple of days will result in considerable weeping and gnashing of teeth."

More Stories By David Geary

David Geary is the president of Sabreware, Inc., a Java training and consulting company. David has developed object-oriented software for nearly 20 years and worked on the Java APIs at Sun Microsystems from 1994 to 1997. He is the author of six Java books, including the Graphic Java series, Advanced JavaServer Pages, and Core JSTL. David is a member of the expert groups for the JavaServer Pages Standard Tag Library (JSTL) and JavaServer Faces; was one of the earliest contributors to the Apache Struts application framework; and wrote test questions for Sun's Web Component Developer Exam. David is the co-author of the soon to be released Core JavaServer Faces, which is published by Sun Microsystems Press.

Comments (13) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Doctor 03/22/05 07:03:26 AM EST

I had practical experience with JSF 1.1 for three month.
Idea actually is great! :D But I think JSF is not ready for real world commercial application development yet. :( It's visual components lib is poor, for example there are not standard paging and sorting compinents for table and etc. Of course I can write my oun components, but I have not time and wish to do it. And what is more, JSF code is green and contains bugs. I think we should waiting for a year, before using it. Now JSF is good only for homepages. :(
Today I prefer Struts.

By the way, anybody knows any JSF-based professional commercial projects?

Clare 09/24/04 07:24:03 AM EDT

I've never used JSF so I can't offer my own perspective, but after reading the article, I'm left with the impression that many of Raible's issues are still valid.

Also, I was wondering if Geary meant "cinch" where the article says "sinch", and "assert" where it says "ascertain."

Raj Madhuram 08/24/04 03:16:42 PM EDT

Check this out:
http://www.kinzan.com/

Renat Zubairov 08/22/04 05:49:30 AM EDT

I like this place in the article "You can obviate that need by using good utility classes that someone else has already written." - for me it sounds like "We''ve created a very nice API, yeah, it isn''t really usable, but there UTILITY classes someone (not us) have written, so just use them"

Dan 08/20/04 06:07:36 PM EDT

They said wait till next version in EJB. We are still waiting. The most important thing said is "Simplicity is not a goal of JSF".

I don''t think Sun is capable of producing an easy to use software development tool. This will place an upper limit on Java''s growth.

Alexander Jesse 08/20/04 09:08:54 AM EDT

Well. I really like Struts. And JSF is in the beginnings. If you look at what happened since this spring, you must say that it is taking off well.
By now you get several IDE''s with good support for JSF (WSxD from IBM, Sun''s Creator, and others).
You can find additional components. Oracle just joined in with a nice component set (ADF faces).

The main advantages of JSF are (my opinion): 1) the component orientation which already leads to the first component market for a Java-web presentation framework. And allows for your own custom components. 2) IDE-friendliness which will somewhat ease the learning curve for average programmers. Even though each team should have an expert on board or standing by close.

The options: If you need to get your app out in two weeks: stick to what you know. If you can invest a few weeks in experimenting and foresee other projects in a similar problem domain: jump on the JSF-wagon.

Matt Raible 08/20/04 05:34:36 AM EDT

Kito Mann and David have said the same thing: I've stated I have a problem with the specs, but there's not much proof in my post.

I'll agree with you both. The few minor issues I
have (no easy way to i18n success messages, no HTML escaping on
and ugly validation messages) do seem to be spec related as
the deficiencies exists in both Sun's RI and MyFaces. I think JSF is a
good idea, and seems easy to work with at first, but from a hand-coding
perspective, there's some silly stuff - like having to load a resource bundle
after the tag. Why can't be in a SiteMesh
decorator? Why can't the resource bundle be declared for all pages, rather than
needing to be declared on each page you want to use it? These are spec issues
IMO. I was also pretty disappointed in the
component. I heard a lot of hype about it and how it was just as good as the displaytag - but it doesn't even come close
to the functionality that the displaytag has. This is fine since I can use the
display tag in JSF - but I can't invoke an action's method with the display tag
and an outputLink. That sucks. I have a few simple thingKito,You and David have said the same thing: I've stated I
have a problem with the specs, but there's not much proof in my post. I'll agree
with you. The few minor issues I have (no easy way to i18n success messages, no
HTML escaping on and ugly validation messages) do seem to be
spec related as the deficiencies exists in both Sun's RI and MyFaces. I
think JSF is a good idea, and seems easy to work with at first, but from a
hand-coding perspective, there's some silly stuff - like having to load a
resource bundle after the tag. Why can't be in a
SiteMesh decorator? Why can't the resource bundle be declared for all pages,
rather than needing to be declared on each page you want to use it? These are
spec issues IMO. I was also pretty disappointed in the
component. I heard a lot of hype about it and how it was
just as good as the displaytag - but it doesn't even come close to
the functionality that the displaytag has. This is fine since I can use the
display tag in JSF - but I can't invoke an action's method with the display tag
and an outputLink. That sucks. I have a few simple things I like in my
applications and JSF couldn't provide all of them easily:


  • A sortable/pageable list of data. It's possible, but you
    have to add special sorting logic for each class. JSP already has this with the
    display tag - I'd simply like to be able to use it in JSF.
  • Bookmarkability. Container managed authentication gives us
    a great way to offer users the ability to bookmark pages. If everything is a
    POST with JSF, we lose this ability. Sure there's the HTMLOutputLink, but if we
    can't invoke actions, what good is it?
  • Clean and easy to read validation messages. The validation
    messages in both MyFaces and Sun's RI are not something you'd deliver
    to customers. What's wrong with making clean messages out-of-the-box? Tapestry
    seems to have no problems doing this. All the other MVC frameworks make you
    specify your own - which is fine with me.
  • Easy cancelling and multi-button form handling. JSF does
    this well - better than the rest I'd say.
  • Easy testability. Because of the plethora of JavaScript,
    JSF apps are difficult to test with tools like jWebUnit and Canoo's WebTest.
    Don't get me wrong, I love JavaScript - but an application should be able to be
    tested w/o it.
  • Success Messages. JSF does success messages OK - it's a
    pity it's not easier to get a resource bundle and it's a shame that you can't
    escape HTML in the tag. This seems like an oversight to me.

I hope these issues are fixed soon b/c I do think JSF has potential. It
simply doesn't meet my meager requirements to write a basic webapp.

Kito Mann 08/20/04 05:30:34 AM EDT

Matt Raible says that the problem is with the specification, not the implementations. However, the only points he makes that are related to the specification are the requirement for form posts and the lack of a simple way to internationalize application-generated messages. (By the way, you can create normal hrefs using the HtmlOutputLink component (), but they can''t execute actions. Most of the issues you mentioned were either specific implementation bugs or issues with specific component implementations. It''s fair to point out that the standard UI components are useful, but they''re really only the tip of the iceberg. Several companies (including Oracle and several smaller companies) either have, or will, be introducing better components. It''s also fair to note that JSF is newer than the other frameworks you''ve used, so you can''t expect the same amount of traffic in the on-line forums.

Kito D. Mann Author, JSF in Action
(www.JSFCentral.com - JSF FAQ, news, and info)

toto 08/19/04 09:51:49 AM EDT

I think Raible is too in love with struts to have a clear sight on what''s going on. I tested recently JSF, and having had not so much pleasure practising struts, I can say I prefer JSF. It requires a little bit more words to get something work, but I like the global approach, and I can feel it will *probably* win the game. We should remember that Craig R. McClanahan, creator of struts and major contributor of the JSF specs, recommends the migration to JSF.

Aris 08/19/04 09:39:44 AM EDT

I just finished a project using JSF. I learned it along the way. I recommend other web application projects to use it, but only after the developers have read the spec. There is a learning curve for JSF that is just as high as it was for Struts two years ago when I knew Struts was a crappy way to do web apps. But that''s not the case for Struts now. I can develop web apps easier,better,faster with JSF because I a software developer, not because JSF is filled with magic pixie dust.

Armin 08/19/04 09:08:06 AM EDT

I was trying to use JSF with struts using struts-faces and myfaces implementation. But after banging the whole day...it seems to me that JSF is still not matured..no clear information...no clear documentation (Like Struts). I can''t believe that Craig R. McClanahan is also on the JSF Reference Imple. Working with JSF is not worth at the moment. Vote for Matt Raible.

Vic 08/19/04 09:04:48 AM EDT

They said wait till next version in EJB. We are still waiting. The most important thing said is "Simplicity is not a goal of JSF". .V

Dim 08/19/04 08:43:46 AM EDT

Just some points more. I''m working with JSF since 1.0 and think it''s the right direction (even I''d like Struts for better javascript, easiness...). Just some complains (may I :-). 1. messages. I need the way to know is there an error for my component (#{empty error[idComponent]}) so I can change css or make another staff. 2. even for someone to get rid of JSP looks a good idea, IMHO most developers use JSP to construct a JSF tree, so more attributes needed (i.e. row/column style access in dataTable - look for SUN forum). Again better integration with JSTL 3. make commandButton image tag context-relative (like in commandLink). 4. make IE support data: URL so we can make cool JSF components with embedded images (joke :-)))