Skip to main content

An Analysis of Peter Thomas's JSF Critical Rant

Posted by edburns on January 22, 2010 at 5:13 PM PST

There’s this guy, Peter Thomas src="http://mediacast.sun.com/users/edburns00/media/ptrthomas.jpg"
alt="Peter Thomas headshot" />, and he has this blog entry called
“jsf sucks”. I don’t want to increase his page rank
so I’m not linking to it here. However, it’s certainly a
popular page since it’s the top link for “jsf sucks”
on href="http://www.google.com/search?hl=en&q=jsf+sucks&aq=f&aql=&aqi=g2g-s1g2g-s3g2&oq=">google,
href="http://www.bing.com/search?q=jsf+sucks&go=&form=QBLH&qs=n">bing,
and href="http://search.yahoo.com/search?p=jsf+sucks&toggle=1&cop=mss&ei=UTF-8&fr=yfp-t-701">Yahoo!.
I have read the entire blog entry, all of the entries linked from it,
most of the comments on those entries, and some of the entries linked
from those entries. It’s a testament to my faith in God that I
can emerge from such an exercise without feeling a level of guilt
tantamount to that felt (one hopes) by a href="http://en.wikipedia.org/wiki/Genocidaires">genocidaire.

I started doing a quantitative analysis of the comments on each
entry, summing up pro- and anti-JSF comments. I only did a spot
sampling of four entries in this way and each of them came up with more
pro-JSF than anti-JSF comments. I believe that if someone proceeded
with such a rotten tomato style analysis, they’d find that most of the
entries had more pro-JSF than anti-JSF comments.

The best summary of Mr. Thomas’s vituperous screed coms from
Benny Bottema, in one of the href="http://blog.projectnibble.org/2009/05/24/jsf-is-a-diamond-in-the-rough-you-just-need-to-make-it-shine/comment-page-1/#comment-685">comments
on one of his posts, which I’ll quote here.

    Concerning your point about a ‘comprehensive list of hyper-linked,
    verifiable references to comments by real people’: I don’t dispute
    that. I said it is an unbalanced pool of information, poisonous in
    fact. With ‘nonobjective biased site of propaganda’ I referred to the
    site owner who compiled the list. Anyone can put together a site, only
    referring to articles that say something sucks. That’s just
    immature. Also the names you refer to are irrelevant, old quotes in a
    time where JSF couldn’t be corrected by supplemental frameworks. Take
    Rod Johnson’s point for example, it’s a quote from 2004 about JSF. No
    mention of its potential or combinatorial qualities... simply JSF
    itself which I already admitted is flawed on its own. And this is used
    as ‘proper’ argument? Useless propaganda I say.

One sensible response to such polemical fulmination is to tag the
articles as appropriate using del.icio.us tags. I have built a href="http://delicious.com/edburns/bundle:jsf-opinion-negative">tag
bundle for this purpose. It contains the following tags

Tag name Articles with this tag express a negative opinion of JSF...
jsf-opinion-negative but the opinion may or may not be substantiated.
jsf-opinion-negative-reason-complexity due to its perceived complexity.
jsf-opinion-negative-reason-misunderstanding but the opinion is based at least
in part on a misunderstanding of JSF.
jsf-opinion-negative-reason-misunderstanding-components but the opinion is based on a misunderstanding of how components work JSF.
jsf-opinion-negative-reason-misunderstanding-decoration but the opinion is based on a misunderstanding of how decoration and extensibility work JSF.
jsf-opinion-negative-reason-misunderstanding-el but the opinion is based on a misunderstanding of how the EL works JSF.
jsf-opinion-negative-reason-misunderstanding-events but the opinion is based on a misunderstanding of how events work JSF.
jsf-opinion-negative-reason-misunderstanding-i18n but the opinion is based on a misunderstanding of how i18n works JSF.
jsf-opinion-negative-reason-misunderstanding-lifecycle but the opinion is based on a misunderstanding of how the lifecycle works JSF.
jsf-opinion-negative-reason-misunderstanding-markup but the opinion is based on a
misunderstanding of how templating and markup works JSF.
jsf-opinion-negative-reason-misunderstanding-persistence but the opinion is based on a misunderstanding of how persistence works JSF.
jsf-opinion-negative-reason-misunderstanding-renderkit but the opinion is based on a misunderstanding of how renderkits JSF.
jsf-opinion-negative-reason-misunderstanding-security but the opinion is based on a
misunderstanding of how security works in JSF.
jsf-opinion-negative-reason-outdated but the opinion is based on outdated information.
jsf-opinion-negative-reason-polemical but the opinion is unsubstantiated
and stated in an unhelpful manner.

In addition to the tagging, which I hope others continue to do using
this vocabulary, I took notes on each one, which I now present here.
Many of the notes say, “fixed in JSF2: <code>” where
<code> is a key in the following table.

code meaning
viewParams the View Parameters feature
ezcomp composite components
ajax JSF2 standard Ajax support
facelets JSF2 standard Facelets
compcompat JSF2 standard component compatibility measures
select* Select* now take Collection of POJO.
exceptionHandling JSF2 pluggable exception handler, better error messages, ProjectStage.
resourceLoading JSF2 standard resource loader
bookmarkable JSF2 standard bookmarkability
navigation JSF2 standard implicit navigation
systemEvents JSF2 standard System Events
annotations JSF2 standard annotations for most stuff
prg JSF2 standard support for POST REDIRECT GET
noWebXml On EE6, you don't need a web.xml if you are ok with /facelets/* and
*.xhtml as your JSF servlet mapping.
el JavaEE 6 standard EL method invocation
flash The flash scope
viewScope The view scope
stateSaving JSF2 standard partial state saving



[2004-03-04] JCP Releases JavaServer Faces 1.0
- I read this entire thread and there are just as many pro JSF messages
as anti-JSF ones. Of course, you chose to extract only the negative
ones.

Also, in the "Programmers So Far Underwhelmed by JSF" article, there
was also positive and negative and you only extracted the negative.

You missed this, "If you would have talked 30 years ago to people
programming in assembler, not everyone was happy seeing C come up," he
told internetnews.com. "That's just evolution, putting layers on top
of other layers, but it's our belief that with JSF we get a very
powerful layer that makes things easier."

"Krause expects JSF critics to quiet down in the next six to 12
months, when the first JSF-enabled Web applications start hitting the
Web portals and sites. His product, W4T, will include JSF in the
coming months, and expects other tool vendors to follow suit."

This is exactly what has happened.



[2004-03-05] JSF: The Ultimate in Flexibility? Or Complexity?
Entirely outdated and somewhat polemical.



[2004-06-09] Improving JSF by Dumping JSP
We've done exactly that in JSF 2.0. JSP is a backwards compatibility
layer only.



[2004-08-06] My JSF Experience
The threaded discussion has about 40% pro JSF comments, but you
don't mention that.



[2004-09-20] Boycott JSF
Citing the bile blog? Come now! I love Hani, he's a rockstar
programmer in my book, but the bile blog was always more about
polemecism than content.



[2005-07-??] Gradebook Taming JSF 1.1
Mr Davis says, "For example, backing beans would do database queries
when a getter hits a null value. In practice, that meant we couldn't
really be sure when the queries were being done or to what
purpose. Some DB queries were issued in the Apply Request Values
phase, some in the Process Validations phase, and some in the Render
Response phase. We'd unexpectedly display old data instead of
freshening from the DB. Or we'd add a "rendered" check to a button and
find that submits had stopped working."

This is a misunderstanding of the JSF lifecycle. Hitting the database
from a getter is never a good idea. In JSF1, you could use a
PhaseListener to do this, in 2 you'd use a SystemEvent



[2006-01-20] JSF Burrito: More Complete List
"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]"

Fixed in JSF2: viewParams

Component writing is much more difficult than writing JSP tags (Rick
Hightower convinced me of this at NFJS)

Fixed in JSF2

Small free component market (compared to Eclipse; probably side effect
of #3) [or even delphi components]

Fixed by 2008

"What's the point of JAAS and all the other security advances made if
we're advised to "throw them out"?"

Who gave you that advice? I show a nice integration of JAAS and JSF
in my JSF 1.2 book. Also, in JSF2, System Events work well for very
fine graned role based access control.

"Unit testing our pages is too difficult."

JSFUnit works well here.

"AJAX components are coming, but it's much more difficult to integrate
it on your own."

Fixed in JSF2: ajax

"Templating seemed difficult to do with JSF"

Fixed in JSF2 facelets. Also, Facelets has become the defacto standard for
templating in JSF 1.x.



[2006-02-10] JavaServer Faces - why?

This is a largely fact-free polemical post. The comments have several
well-reasoned favorable responses to JSF.



[2006-02-21] Usability problems in JSF
Thanks for including a post from our star expert group member Adam
Winer. Adam was instrumental in bringing JSF to the level of success
it currently has.



[2006-05-03] Where JSF and Portlets went wrong...
"(try using ICEFaces components with ADFFaces)"

Fixed in JSF2: compcompat. This was a central focus of JSF2. We'll
know it's fixed when all of the parties have released JSF2 versions of
their libraries.

"While third-party options (like Facelets) do make programming with
JSF easier"

Fixed in JSF2: facelets

There were a number of positive aspects to this post but you chose to
only extract the negative ones.



[2006-05-19] JavaOne: Google Web Toolkit vs. JSF
More than half of the comments on this blog entry are pro-JSF.



[2006-06-19] JSF Rough Spots
"selectItems tag is way too unflexible - it only takes a Map. You'd
think you should be able to show a simple String array or a List of
Strings, but no."

Fixed in JSF2: select*

"The EL should be able to, as in OGNL, create objects has it comes
across the need to."

This one I don't understand. The JSF EL has always done this.

"Every JSF page must define and load its resource bundle. I'm probably
getting this wrong, but AFAICT, this is required. If true, this seems
redundant and inefficient."

Fixed in JSF 1.2 (2007)

"JSF exception messages weren't very helpful."

Fixed in JSF2: exceptionHandling



[2006-09-08] JSF and RSFHistory
I note that RSF hasn't been updated since 13 September 2008 for
its 0.7.4 release. Does anyone know if this is still an active project?



[2006-09-13] Geebis Blog: Wicket
"The biggest reason is that creating custom components in JSF can be
difficult, especially if you want your components to have lots of
javascript/css that it contributes to the page."

This problem has been solved very well in JSF2. The combination of
composite components and resources is a very powerful answer to this
person's problem. Fixed in JSF2: resourceLoading

Also, Ken Paulsen and Jason Lee wrote a nice article about how to do
this in JSF 1.x at
http://java.sun.com/developer/technicalArticles/J2EE/jsf_templating/.



[2006-09-16] Tinman and the Scarecrow
"In JSF, you cant copy-paste a url into a new browser and expect the
same page to show up."

Fixed in JSF2: bookmarkable. Also, the PrettyFaces JSF add on does this even
better.

"JSF has a rudimentary IoC container somewhat inspired by Spring;
though nowhere near as powerful"

Many sites have been using JSF and Spring in production for at least
three years. Also, the IoC container in JSF was inspired by ATG
Dynamo and in fact pre-dated Spring by a month or two in concept.

The rational for this rudimentary IoC container built into JSF is to
give a useful experience to JSF users that want to use straight
tomcat. JSF + Tomcat was the lightest weight full stack IoC container
when it came out in 2004. Much lighter weight than Spring at that
time.

Nowadays, you have many options here: CDI, Guice and of course Spring.

"JSF uses absolute, declarative navigation enforced by lengthy XML,
triggered by passing string-keys around--pretty piss poor design in
this day and age and quite clearly a legacy of Struts."

Fixed twelve ways to Sunday in JSF2: navigation

"For some bizarre reason, JSF does not play well with the JSP
errorPage directive."

Fixed in JSF2: exceptionHandling. Not just that but there is a pluggable exception
handler.



[2006-10-19] Faces: The emperor has no clothes
"Then the hell of linking pages together starts."

Fixed in JSF2: navigation

"Not trying to be sarcastic here, since Facelets is pretty good, but
this complicates the hiring and education of the team and in fact
invalidates the selling point of Faces 'being a standard'."

Facelets is now the standard.Fixed in JSF2: facelets

"The spec is heavily based on two things: POST params and (ugh)
forward navigation rules, that are default. In my previous life
forward was the exception, not the norm."

POST is still the default, but it's much easier to do proper POST
REDIRECT GET, or GET REDIRECT GET in JSF2.



[2006-12-15] Nightmares on JSF Street in Trinidad
This post has very little to do with core JSF and instead talks about
the Trinidad JSF component library.



[2006-12-19] Reasons to choose Wicket over JSF and Spring MVC
"I liked its form handling and navigation support but I did not like
all the javascript and extra markup that was inserted into every page
without me asking for it."

As Jason Lee said in the comments, all you need to do to not have
JavaScript is avoid using h:commandLink. Now, with JSF2, you have the
additional step of not using Ajax, because it's really hard to do Ajax
without JavaScript (though I heard you can do Ajax with CSS and no
JavaScript).



[2006-12-26] not enamored by JSF 1.1

I found this thread to be largely fact based. I think this is a great
way to discuss APIs. Unfortunately, this discussion pertains to a
version of the spec that is over five years old.



[2007-01-01] JSF in 2007
Here we can see the influence of Seam on people's opinions. Note that
most of the good ideas in Seam went either into JSF2 or into CDI.

In the TSS comments I see, "Above all I think the Java community need
to get away from premature standardisation of APIs, and let time and
experience decide."

This has been my approach to developing JSF2 from the beginning, and
I'm happy to see all the different ideas from many different sources
in there.



[2007-01-18] Tech Talk: Ed Burns on JSF 1.2
"Make it trivial to design custom components. I am not saying make it
easy. I am saying make it trivial."

Composite components to the rescue. Fixed in JSF2: ezcomp

"There is no "page load" event handler to do initialization."

System events make this even more fine grained in JSF2. Fixed in JSF2: systemEvents

As the author of this talk, I don't see how it supports your argument
about JSF.



[2007-02-19] JSF is cool but it is too young and it has too many bugs!

We live in an age of super-heterogeneous development stacks. In this
world it's very easy to run into situations where the various layers
of the stack interact poorly. The author would have been well advised
to check into one of the forums of the component libraries in the
stack.



[2007-02-28] JSF Anti-Patterns and Pitfalls
Nice that you quoted Dennis Byrne's article. He was a leading light
in the MyFaces development for JSF 1.2.

Also, any technology has its collection of best practices and gotchas.
The fact that those for JSF are so well documented shows its vitality.
Let's take a look at Dennis's subsections.

The Deja vu PhaseListener

Fixed in JSF2: systemEvents

XML Fetishism

Fixed in JSF2: annotations. No XML is required. Not even web.xml. Annotations
are available for everything according to the 80/20 rule.

Thread safety

These issues are inherent in distributed multi-user systems design.
The same issues will arise for shared objects in any web framework
that uses the Servlet infrastructure.

Facelets Migration Challenge: Tags with Behavior

Putting behavior in your tags has always been discouraged. Dennis
is simply adding to that chorus.

Law of Demeter

This one has nothing to do with JSF specifically and is simply a
best practice about EL.

Code to Interface

This one has even less to do with JSF or EL or web frameworks. It's
simply an axiomatic truth: make as few assumptions as possible by
depending as little as possible on specific contracts. In Java,
that means using interfaces correctly.

View state encryption

Note that turning on view state encryption in JSF is as simple as
setting a content-param. How do you do that in Wicket?



[2007-03-17] JSF - Still pretty much a steaming pile of donkey turd

The author clearly does not like frameworks where the UI is built
declaritively with markup that stands in for anything. He prefers
plain HTML. For him, Wicket may be better. Also, he mentions the
error messages problem, which has been solved for years with facelets
and now solved in the JSF2 standard.

Comments have:

"I would have thought minimum requirements for a web layer toolkit would include:

- *not* being forward based, e.g. should support Post-Redirect-Get out of the box

- *not* baking in view artifacts, like referencing JSP pages. Use logical view names and allow a view resolver to work out what view technology is being used.

- Having a halfway decent notion of a conversation as well as rich *navigation*.
"

All of these are fixed in JSF2: prg, navigation.



[2007-04-16] JSF still sucks?
I wonder why you didn't extract this quote from Matt Raible, "IMO,
Facelets is very easy to learn. "

He also talks about "developer abandonment". Well, here we are now
nearly three years later and there's more interest and development in
JSF than ever. That's not very abandoned.



[2007-04-26] Creating a jsf div component

The article point out the steps that used to be required for building
a custom UIComponent in JSF 1.2. None of these are required any more.
A custom component can be just a single Facelet page.



[2007-05-14] A Wicket user tries JSF
"Wicket does not require any extra XML config like you have
faces-config.xml for JSF"

In JSF2, you don't need faces-config.xml. IF you're on EE6, you don't
need web.xml either. Fixed in JSF2: noWebXml

"Wicket does not require JSPs"

JSF2 doesn't require JSPs either. Also, the .xhtml extension is
automatically mapped to JSF. Fixed in JSF2: noWebXml

"Navigation logic is performed in pure Java code which is much
more..."

JSF2 navigation can be done centrally or per-page but it's always
declarative. JSF2: navigation



[2007-05-22] Rethinking JSF - The Real Problem
The discussion on this thread was too mammoth to review in my limited
time. However, scanning through it, I see an even balance of pro-JSF
and anti-JSF positions.



[2007-05-23] Six Things JSF Breaks (and How To Fix Them)
I like this post. It is exactly correct and none of the
recommendtions he makes are onerous, except for the desire for
completely standards compliant XHTML. For simple pages this is
possible, but when you use advanced components it is hard to
guarantee.



[2007-05-25]

Comments

JSF2 is (unfortunely) not always a solution

Sun is now speaking everywhere about J2EE 6 and JSF2, but unfortunetely for those of us working on the field, these are dreams still far far away. On my job, I have to handle with JSF 1.2 applications that are running on top of JSP 2.0 (that's right, no typo) containers, thanks to Facelets and a few jar hacks. These are very important customers, but they won't update any time soon for a JSF 2, compliant container. And this is true for many of us out there.

Stuck on previous versions...

Yes, some projects are stuck on previous versions of JSF.

Fortunately, with a few exceptions (like ICEFaces), it should be possible to upgrade to 2.0 with no loss of functionality. Bug your app server vendor to come up to speed on the latest version of Java EE.

In cases where the company you are working for chooses not to upgrade - that may be the right decision. For large projects which are working well, there's rarely that impetus to upgrade. It may also be the wrong decision, and as a technical resource for your company, it's up to you to make the ROI pitch.

This is not a problem that's unique to JSF - other frameworks, such as Spring, PHP, and ASP have this problem as well.

I fail to see why this should stop the spec lead of JSF 2.0 from talking about JSF 2.0 features.

JSF has the same problem as CDI: biaised people

So what? Almost every customer using Struts or Spring MVC or even plain Servlets won't take the risk to move to anything else either.
It's better to start new projects with JSF2 than trying to convince your customers into upgrading the app they already spend millions on and which satisfies their need for the moment.


Anyway, my point: JSF1.2 and JSF2.0 are great frameworks. I've been following JSF since 2004. Oh dear, JSF1.0 was far from perfect. JSF1.1 was much better already, and JSF1.2 just works fine.
From there on, I consider JSF2.0 as a set of major improvements on something that already proved to be reliable and ready for production. I have myself put a few medium-to-big JSF projects into production without any serious problem during development or deployment. Indeed, if you take advantage of the extension abilities of the framework, and use Facelets (now standard), and RichFaces/IceFaces on top, you can build great websites really fast. Naturally you need to climb the learning curve, but it's not harder than any other framework.

So many people criticize JSF1.0 in 2010...the same way they criticize EJB2 (regarding other CDI discussions). It's irrelevant and not worth commenting on.
What if I started criticizing the Boeing Stratocruiser, initially based on a B-29 and released in 1950? Wouldn't you say I'm dishonnest not to talk about the 787 Dreamliner and its first flight last month?

So many people also fail to understand a standard like JSF passes through a complex process in a whole EE release. It's serious stuff, it involves dozens of projects, hundreds of people, and puts the Java world at stake every time. And you need to make compromises. But the next version will fill the gaps, as with every other framework.... except other frameworks will evolve in beta version for years, regardless of any constraint or backwards compatibility...but it seems many wanna-be architects take the word "standard" as an insult. And it's just awkward and stupid.

And some recurring arguments, like bookmarkable URLs are also irrelevant. I never had a problem with them. All you need to do is specify #{param.args} in the managed bean behind your page in faces-config.xml, write the appropriate setters in that bean, and handle the logic in a @PostConstruct...If you can't do it easily, you need to RTFM again. JSF2.0 makes it even easier. Great, we should be thankful for that!

Personally I've stopped trying to convince people with prejudice to use JSF. If they don't want to use it, fine by me. I'm just expecting they leave me alone.
There are other very good solutions for enterprise use or not (GWT, Flex, Wicket, etc) and I respect that. They are really cool stuff too, with strong points and flaws as well, naturally.
However, I have personally seen Ed Burns making a presentation of JSF2, coding a few examples live, and literally convincing the crowd it was a really strong framework. THAT tells volumes.

My 0.2p worth

I thought I'd leave a quick comment before starting some real work.

It seems many of you responses are, "Fixed in JSF 2" Well that for me speaks volumes. If a framework is supposed to make a developer's life simpler by taking care of mundane, repetitive or difficult stuff JSF failed big time. Why should I use a framework which requires addon libraries, hacks and such to make it work as expected. Having to wait ~4 years for for the panacea release (oh I mean JSF 2) is an eternity in software development.

A long time ago I tried JSF, and found I was wasting too much time fighting the framework (I wanted a book markable url). So dumped all the JSF books I bough on to my Crap tech book pile and moved on, and will NEVER come back.

All the best

Peter.

Using that logic...

Using that logic, you should also avoid Java.

After all, the 1.0 JDK was slow and had no support for multibyte character sets, not to mention AWT.

You should also probably avoid computers in general. After all, the first versions were made with tubes - tubes! and needed to be programmed with DIP switches.

You don't name what your preferred technology is, but I'll wager that their earlier versions also had issues. (And continue to have issues today - every technology makes tradeoffs.)

I'd also note that many, many folks have had success with using JSF 1.2, including making bookmarkable URLs (as mentioned later in the comments here)...

Experiences from so called "real life projects"

First of all: I spent almost one day reading through Peter’s link list (almost, because some of the comments, posts, etc were already known to me) and Ed’s response. That was a great kind of work, to analyze and categorize nearly all of the not always that objective third person comments, without becoming polemic yourself.

The project currently uses JSF2 (reference implementation) without any additional component library or extensions in a midsize project, that heavily depends on a custom design, a sometimes clumsy old CMS for editorial maintenance and third-party javascript integration for fancy effects. The underlying domain logic is complex enough for not being comparable with rather simple “example” applications like blogs or guestbooks.

From my perspective Mojarra 2.0.2 seems to be more mature than the currently used and recently released DI container spring 3.0.0 and I suppose the quality (documentation, test coverage) of springsource products is one of the best around in the opensource world.

Following Peter’s and followers pain reports, I have to admit JSF is indeed a highly complex piece of software for web application development. Not comparable with Struts in any way for example. If you are planning to introduce JSF for a new project, I would like to advice you to get some people with JSF experience for your team. With “JSF experience” I mean guys, who have actually read the specification, know why things do not behave as expected and could explain this other team members. In general the problem is not caused by JSF, but rather by the developer who misunderstood some of the concepts of JSF.

From my experiences the creation of controllers, converters and validators and the usage preexisting component is not a problem for JSF unexperienced developers. There is none to little of API in form of simple interfaces or event classes to fiddle around with. But if you are going to change some of the fundamental behaviours of JSF, you need to get in touch with all these classes that are used in some phases or thoughout the whole request lifecycle. There are so many extension points in JSF, that even experienced developers often do not get the right point in the first place for their implementation requirements. I have not count them all, but making a rough guess I would say there are about two to three dozen of extension points for an application. These are mainly accessible via decorator or bridge pattern, that is why there are so many abstract classes are out there.

Even though these extension points are one of the reasons for JSF’s complexity I love them. I love them because they enable my team to create awesome application with high level abstraction in general from protocols, states and so on in general, but the ability to extend at low level where needed.


br, Sven

Dear Mr. Burns

I appreciate the time and effort you must have taken to painstakingly analyze and respond to the content of that blog post (yes, I know how hard it is).

I on the other hand, see no reason why your page rank should not be increased - so I will clearly link to this article from the blog post that offends you so much.

But no, I'm not going to include a picture of you as well :P

I can understand why you'd be upset and I am genuinely sorry it had to be this way. It is indeed true that I'm hugely critical of JSF and my intent was to collect a list of references, written by other people. I painted JSF with a large black brush and it looks like you just did the same to me. That's only fair.

Anyway, now that you have here your detailed response (that's what the Internet is for isn't it?), the right thing to do is as I said - clearly link to your post - and offer readers a chance to peruse both sides of the argument.

I'll stop short of linking from this comment to a couple of my other blog posts (you know, page rank ;) but for those who care to look - I have been working on a highly objective comparison of Java web-application frameworks (including JSF), which includes performance test and memory profiling data.

Which sure beats doing things like "quantitative analysis of the comments on each entry" IMHO.

- Peter

Regarding web frameworks

As I am still considering myself as quite new to Java - especially for web development, I looked at the most frameworks that are in the news on a regular basis. For instance tried JSF, GWT with and without Ext GWT, Wicket - I think those are the currently top rated frameworks. I find major drawbacks within all these frameworks. - In JSF I had troubles with accessing component data and GUI destroy-issues in the designer (using NetBeans of course) - some things not really intuitive here. Anyway, looking at GWT the compile time (in the background compiling to JavaScript) is awful slow already for a hello world type thing, not even trying to imagine compile time for a big application. I further had/have rendering issues with Ext GWT. I loved the Wicket because it got rid of all the XML shit (I really hate XML because in 90 % of the cases it is used in a field where other formats would do a better job - just of the fact that the format makes it impossible to write a performant parser) - I love that plain Java idea. However, I found that it lacks GUI elements (at least looks like that for me) and it is completely missing a GUI editor as GWT is that missing also on the NetBeans side (and don't know about the quality of the plugin for Eclipse). - And yes, WYSIWYG GUI design is an essential point for me. So I think, the optimum framework is yet to come, none of those I found is really making me happy. However, even after reading a lot of negative stuff about JSF I am quite sure that JSF would not be the worst decision. - I didn't settle for a specific framework yet. For those who now come over with the argument that for each project the best fitting should be chosen, let me say: I am working in a small company where it is extremely important that my components are reusable for other projects because often one customer is not willing to pay the real amount of work so that we have to count on multiple times selling things to create the revenue. So I cannot create the same things in different projects all the time for new (there are some elements needed in quite every app and so I would have to build same things over and over again for each framework). I am quite on the newest stuff (Java 6, NetBeans 6.8) and don't have legacy Java projects that would tie me to a particular framework. So I am also not prestressed. Decision is very hard for me, but e.g. when looking on this - http://www.youtube.com/watch?v=93uciX4eUbQ - I have doubts that web applications in general are way too hyped and I will think twice before setting up an application as web app. It's mostly the Windows development guys suffered from those plenty setup problems doing everything as web application now. But it could be so easy by downloading and double clicking a jar (or even just use a JNLP Java webstart link. Sure, there are applications that are supposed to be a web app - and I am still not sure which framework to settle on. Habe to try them all again I think. But my main message is: The existing frameworks are all great and all suck to some extent. But I am happy that I did not settle on .NET (although I come from Windows development realm) because there I have only one choice that ever works on Java too if I want to avoid any of those frameworks.

Reusable Components

Hey, if you're looking for completely reusible components, JSF is pretty good at that.

Here's how you can create a JAR file with reusaible Facelet components in JSF1.x: http://ocpsoft.com/opensource/create-common-facelets-jar/

Also, if you're looking for that polished look & feel - PrettyFaces can help you tame those URLs (even in JSF1.x) - "parameterized URLs for client facing apps"

Actually, JSF2 improves on reusable components even further, but I haven't written the follow-up blog entry yet. You're completely right, though; every framework has its pros and cons.

--Lincoln

What is a component

Hi! There is a lot of discussions around the issue of what java web framework is the best. Much of those considerations refer to a notion of a "component". I surfed quite a while trying to find out what different sources mean by "component" and came to a conclusion that almost each java web framework means different thing. Also some are talking about View components. Other about Action(Controller?) component. Some about Model components and further on in some combination.

On the other side we have (and apparently love) the MVC paradigm. So what is the relation between paradigm of components and that of MVC? Should a good component Model mean applying MVC principle to each component?

So far I found only one relatively clear set of statements defining such kind of MVC component model suggested by some hardly known technology here: http://www.hybridserverpages.com/framework.html. May I ask everybody's opinion: how do our mainstream web frameworks (JSF, Wicket, Struts, Spring and so on) compare against that list of features? How do those frameworks handle the interference of two paradigms?