Link Details

The final conclusion of the blog post says "So, what is alternative? My suggestion is to use JSPs, servlets and JavaScript libraries."

Also the author may consider using Tomcat 4 and a Celeron processor based server. While as a user of JSF I do agree that it has its own drawbacks, the conclusion need not be JSPs, Servlets and JavaScript libraries.

It depends on the type of person you are, I have observed people who are happy with the tag-soup / declarative nature of JSF, and these are typically people who a) have not tried other frameworks b) have little-to-none HTML / CSS skills and c) prefer to code in tags and EL instead of Java. I think the problem here is that for a person with a good understanding of HTML and JavaScript - just to take an example, the kind of HTML that JSF components generate (using tables for layout etc.) can put you off completely.

And for e.g. there are lots of people who feel that JavaScript widgets talking to a REST back-end are the way to go, see this DZone link for e.g.

http://java.dzone.com/articles/java-server-faces-vs-ajax

So if JSP is used just to wire up some JavaScript widgets this is a perfectly valid approach. Certainly no need to invoke Tomcat 4, Celeron and whatnot.

The usage of JSP with Javascript widgets may not be better than using a readily available component in a web framework (not just JSF but any framework) for all the use cases in an application.

Lets take displaying a certain number of images as slideshow. It would really benefit the client (who pays for development) as well as the developer (already the testing is done for cross browser compatibility etc by the community whether open source or any other license) to readily use a component from any web framework (In JSF, i would use http://www.primefaces.org/showcase/ui/imageSwitchSlideShow.jsf).

IMHO, Trying to do it using JSP plus Javascript widgets (though a valid approach) needs more time to implement than using a readily available component in any of the framework. So we cannot rule out using components in a web framework (again i dont say JSF but any web framework). Hence the final conclusion of the author is like going back in time.

LOL. Just do view source for the so-called "SlideShow" you linked to. It is using *both* jQuery and YUI. PrimeFaces is just wrapping all that, of course it is going to be reasonably cross-browser compatible, thanks to jQuery and YUI, not PrimeFaces. If one can write a JSP custom tag to simply wrap readily available JavaScript widgets, why not?

Not that I would choose JSP, but just saying it is a perfectly valid choice for some projects, not "going back in time" like you say. Wonder what you would have to say about things like GSP from the Grails world :)

I have done view source many time and very well aware that JQuery, Prototype, YUI, Scriptaculous ... and other frameworks are used. For your laughing aloud,=> So its not that an ignorant moron is typing the comment :)

I am just debating about the time needed to use a component in a web framework with sugar coating over the Javascript widgets versus readily available JavaScript widgets. When passing arguments back and forth multiple times in a long conversation, good luck for a project with only your plain Javascript widgets.

Nobody is questioning whether *you* have done "view source" - but some of those reading the comments here may have been fooled by your FUD saying that JSF is so great because components are cross-browser compatible. LOL because cross-browser compatibility is because of JavaScript - which you were initially trying to argue against.

I'll stop here rather getting into a debate as to what kind of "long conversation" you were expecting in a simple slide show of a bunch of images :)

As now it is clear that I am not arguing against JavaScript but against using plain JavaScript widgets, in the slideshow if you think of a fixed set of images it is simple.

How about developing a use case to display latest 5 uploaded images as a slideshow in an application? May be we can post the code for two applications, one with plain JavaScript widgets and one that uses any web framework component library in our respective blogs for this scenario (to realize which approach takes less time to come up with a use case implementation) rather than spending time in these comments.

So you both dont care about AJAX

>LOL. Just do view source for the so-called "SlideShow" you linked to. It is using *both* jQuery and YUI.

*Of course* it does. How do you think these fancy widgets would otherwise be implemented? I hope you don't have some sort of crazy idea that widgets are rendered server side to a pixel bitmap and then send to the client or so?

The beauty of JSF is that it's a very nice connection of client-side code to server side code. With most good JSF component libraries it's trivial to hook them up to my backing beans or if needed directly to my services. The server side component model of JSF ensures that components can easily be assembled and utilize the uniform event system.

Components in JSF can be very lightweight, barely more than and old JSP .tag or fragment, just a bit more formalized. Or they can be more heavy weight for those cases where it makes sense.

Just took some time to code the sample use case. Please check out the project from

http://code.google.com/p/karthikeyanc/source/browse/#svn/trunk/exampleprojects/slideshow

I have placed the file upload and slideshow in a single XHTML file at http://code.google.com/p/karthikeyanc/source/browse/trunk/exampleprojects/slideshow/src/main/webapp/home.xhtml

With JSF 2.0's composite component feature, you can create your own HTML+CSS+Javascript thing the way you like it and you get optional reuse, validation, conversion, events ajax and more as bonus. JSF gives you the flexibility, if you like HTML+CSS+JS, you can ignore the component library ecosystem and create your own composite stuff, on the other hand if you don't want to deal with complexity of html+css+js and want to focus on business instead of reinventing the wheel, pick a JSF component suite.

@pt93903 As for PrimeFaces, I assume you haven't used PrimeFaces as you've concluded that it's just a wrapper.

1, do you enough market research? Could you confirm your website can obtain recognition?
2, your profit model is what kind of? If there is actual profit plan?
3, you have enough of supporting your website content? After the completion of the construction site to your website to source?
4, besides the site itself, and you can use what the off-line resources? Are your strengths?
Five, how are you going to promote your website? How to quickly find your audience?
Six, you have enough to maintain site operation of funds? (including server rents, team salary),
（ http://www.thefitnessshoes.com/mbt-m-walk-men-c-8.html ）Cheap Top Quality Fendi Shoes mbt walk mens
（ http://nikeairmax2u.com/wholesale/Nike-Air-Max-2011-666_p1.html ）Replica Puma,Lacoste Trainers
（ http://2buyprada.com/wholesale/Juicy-Couture-Lucky-Thong-Sandal-685_p1.html ）Women's Shoes boots juicy couture lucky thong sandal
（ http://gladly2shop.com/wholesale/Nike-Air-Griffey-Max-1-727_p1.html ）Channel boots mbt sport thefitnessshoes.com
（ http://www.7x24gucci.com/wholesale/Gucci-High-Top-Men-Sneakers-552_p1.html ）In online shopping Gucci High Top Men Sneakers

Religious war :-)

P.S. In my opinion JSF is worse than Oracle. Sun actually lost web development with JSF

You dont put JQuery on ipad

I agree with quite a bit of the article.

When I started tinkering with JSF, using Netbeans, I dropped a "grid" control onto the page, and viewed the end result int he browser. When I realized it dropped a Dojo based grid on the page, I deleted the project, never to use it again. I also greatly enjoy writing Javascript, and use JQuery for the majority of my work.

On another note. I've been writing Java Web apps for several years, and I've never assumed that using JEE meant that I HAD to use JSF any more than it meant I HAD to use any other specific part of JEE.

Indeed, that's an important aspect of Java EE. You don't HAVE to use anything it offers, but you use as much or as little as you need. If you want to build a small web site build with pure Servlets and JSP, then this is an option. If you want to use EJB3 and JPA, but not JSF and use Wicket instead, the choice is yours.

That said, I did found that most of the things Java EE offers (especially Java EE 6) are the best solutions on the market. I greatly enjoy the power and flexibility of JSF and also importantly, the wealth of resources available for it. JSF is now the most used modern web framework. Only ancient Struts 1 still seems to be used more. No matter how nice some alternative web frameworks like GWT or Wicket are, their adoption is quite minimal compared to JSF.

>> JSF is now the most used modern web framework

Yes Arjan, we believe you :) Here's an interesting fact. Guess the number of production ready JSF 2.0 libraries that exist as of today.

Answer: 1

>Yes Arjan, we believe you :)

I'm not sure if you mean this sarcastically, but the truth of the matter is that JSF is used a lot and Wicket is barely used. I read an interesting article about this on tss recently and many surveys and trends show this. For example, consider this trend line for available jobs:

http://www.indeed.com/jobtrends?q=java+jsf%2C+java+wicket%2C+java+stripes%2C+java+struts%2C+java+gwt%2C+java+seam%2C+java+%22spring+mvc%22&l=

and without the leader (Struts):

http://www.indeed.com/jobtrends?q=java+jsf%2C+java+wicket%2C+java+stripes%2C+java+gwt%2C+java+seam%2C+java+%22spring+mvc%22&l=

Clearly JSF is used a lot. GWT and Spring MVC are the runners up, but I don't see Wicket doing too well here.

>Guess the number of production ready JSF 2.0 libraries that exist as of today.

Funny one, it's 1 already while JSF 2.0 hasn't been released that long ago. Now a question for you: Guess the number of production ready JSF 2.0 libraries that are in development and about to be released.

Answer: 9+

Yet another one: Guess the number of JSF 2.0 libraries that are in development:

Answer: Pretty much all of them.

This just proves to me that more and more Java developers are not "really" web centric developers. It's reminds me of the Java guys who use JPA and Hibernate, yet don't know SQL. I usually fix their data access layers, and rewrite their queries to run in 200 milliseconds as opposed to 3.

It's [sic] reminds me of the Java guys who use actual Java statements and classes, yet don't know byte code. I usually fix their algorithms, and rewrite their code to run in 200 milliseconds as opposed to 3.

(btw, I do have you meant 3 SECONDS, since rewriting a query that normally takes 3 milliseconds to take 200 milliseconds is not much of an improvement, is it)

Anyway, jokes aside, both JSF and JPA largely abstract from HTML respectively SQL. But mind you, they still provide a very wide open gateway to the lower level stuff. In JSF it's ABSOLUTELY TRIVIAL to just write HTML and encapsulate that in a dirt easy component for integration with your business code. You very simply have a choice, you can use pre-written components are just jot down some HTML and wrap that.

The same holds for JPA. It's got a perfect interface to SQL: createNativeQuery. Results from native queries can be used as is (pure scalar native queries or batch updates), can be used to very easily construct a new object, or can be used to populate a JPA entity via its existing mapping. Often this can also be done completely transparently: I first define an annotation with a named JPQL query, which my DAO or whatever uses then. If I find a situation where a native query would do better, I define a native named query with the same name, put it in some XML file and this will then automatically be used. Great for just trying out whether the native query really improves stuff.

Over time, JPA compilers have to potential to actually optimize the SQL they generate. They don't do this now, but they will. In the past people also didn't believe C or C++ compilers would ever outperform handwritten assembly (hence the early popularity of embedding asm code in C/C++). But eventually C/C++ compilers got so good at optimizing that no one in his right mind writes business code or even most parts of embedded code in assembly anymore.

No, of course I mean to say "it's" there. Thanks for pointing out the obvious. That was clearly an error, as I was doing other things besides commenting on dZone all day, then proof reading my comments.

Yes, that's 3 seconds. Again, thanks for pointing out the obvious. I cannot actually believe that you would take the time to write all that out, as anyone reading this forum would likely know that.

Byte code? Seriously... SQL is hardly on the same level of abstraction as byte code.

>Byte code? Seriously... SQL is hardly on the same level of abstraction as byte code.

You have to look at it in relative terms. SQL is to JPA as what byte code is to the Java language. JPA compiles to SQL. With JPQL this is fairly obvious, but the same is true for the 'normal' entity manager operations and the criteria API. Both are high level languages that abstract from a lower level language.

Indeed, very few people have written byte code by hand, but in the case of assembly vs C/C++ the analogy might be more clear. Assembly -was- written by hand, and years and years after C was introduced this was still not a strange thing to do. I learned assembly in the mid 80-ties and by then it was still a perfectly normal programming language and not considered to be extremely low level. C was then still seen as a "higher level" language. Now, we normally wouldn't use the qualifier "higher level" for C or even Java anymore.

SQL might go the same way. If you think I directly compared SQL to byte code (or assembly) then you're just missing the point. SQL is of course not byte code, but just as byte code is abstracted by the Java language, so is SQL abstracted by JPA.

And just as early byte code and assembly optimization was sub par, so is SQL optimization by JPA today. But this -will- improve. So today your manual optimizations still pay off, but they might not be necessary tomorrow.

I don't entirely disagree, but my point is that byte code and Assembly are much more complex than SQL. I totally get the point you are making with regard to JPA being an abstraction over SQL. I'm just not sure that SQL generated by these APIs will ever get to the point of performing as well as SQL. I have used JPA / Toplink in the past, but not lately.

Can you now handle inline cursors, hierarchical queries, queries with partitions, etc ? without using createNativeQuery?

Also, I didn't like Toplink querying 50 "objects", then doing 50 queries per object to get a child collection populated. I know that lazy fetching can be utilized. However, if you make use of the child collection on all 50 of those objects, it would have been better to get all the data in a single query.

There are a few other subtle things such as that that have always lingered in the back of my mind when dealing with JPA.

Well, I do understand you have doubts whether SQL generated by JPA will ever outperform SQL. A lot of people think it will eventually, but of course nobody can really see the future. We also thought that CPUs would be running at 20Ghz by now, but as we all know this didn't happen ;)

>point is that byte code and Assembly are much more complex than SQL.

I know what you mean, but just to clarify: you mean here that byte code and asm are much more complex to humans. For machines it's the other way around and therefor compilers are currently pretty good in optimizing asm, but not good in optimizing SQL at all. This is because SQL is a declarative language, which means the compiler must understand *what* results the user wants instead of grasping of *how* the program does what it does (as with imperative languages).

>Can you now handle inline cursors, hierarchical queries, queries with partitions, etc ?

Not yet, so createNativeQuery remains an important tool in JPA. But this too is not unlike the asm -> C/C++ situation. Even in 1997 asm and intrinsics were still needed to take advantage of things like the MMX instructions in Pentiums CPUs. At that point, no compiler could generate code for those.

We do see that JPA is slowly adopting additional SQL constructs. For example, in JPA 1 pessimistic locks (i.e. select for update) were not supported. In JPA 2 they are.

At the current rate it might take a decade or even longer before JPA implementations generate some sane and reasonably optimized SQL, so in the mean time those manual optimizations with or without createNativeQuery will remain necessary ;)

>At the current rate it might take a decade or even longer before JPA implementations generate some sane and reasonably optimized SQL

There's also an additional force working towards better JPA (ORM) performance: database vendors start noticing that ORMs are use more and more and are optimizing their planner to recognize several frequently occurring patterns of code that ORMs generate.

Oh please. I have a healthy disgust for people who use "job trends" from Indeed and the like to argue technical discussions. Especially when you can generate graphs in all kinds of ways to suit your needs. For example, take a look at this graph that shows astounding growth for wicket compared to JSF. Hmm, it actually might be right :P

http://www.indeed.com/jobtrends?q=java+jsf%2C+java+wicket&relative=1

Now YOU are the cheat here. I'm sorry. The obvious thing to do would be to just take my graph and click on the relative link. You would then have gotten this graph:

http://www.indeed.com/jobtrends?q=java+jsf%2C+java+wicket%2C+java+stripes%2C+java+struts%2C+java+gwt%2C+java+seam%2C+java+%22spring+mvc%22&l=&relative=1

Ouch! That does hurt, doesn't it?

*That's* why I said GWT and Spring MVC are the runners up. I DID look at the relative graph you know. Wicket had some relative growth in the past, but with such minor numbers this is quite a different story. In the extreme case, if you go from 1 to 2 users, you have 100% relative growth. So just 1 extra user gives you 100% relative growth. A technology with say 100.000 users needs, right... another 100.000 users. So if this other technology still grows and gets an extra 50.000 users, while the obscure tech gets 1 puny extra user, the obscure one has a higher relative growth.

In this case you see that JSF continues to grow, and in absolute numbers JSF attracted *FAR* more new jobs listings than Wicket did.

So there is obviously more demand for JSF right now than there is for Wicket, and in absolute terms this demand increases faster than demand for Wicket increases, what else is there to say?

>> Now YOU are the cheat here

Ha, ha, that's the whole point :) There are lies, damn lies, and statistics.

Really, you need to lighten up a bit in these comments. I couldn't help chuckling aloud seeing you go all "grammar nazi" on the other commenter, poor guy.

>> Ouch! That does hurt, doesn't it?

Huh? Hurt who? Interestingly, this DZone link (and thread) was all about JSP and JavaScript until JSF fanboys dragged in GWT, Wicket and the like. Personally I like the graph because at least it seems like the era of Struts is over *shudder*. By the way you missed Grails in the graph.

Isn't it great to see the wide array of choices and healthy "ecosystem" in Java web-framework land :P Go GWT ! Go Spring MVC !

>Ha, ha, that's the whole point :) There are lies, damn lies, and statistics.

True, so a single graph can be quite deceiving, but take a look at the data from multiple angles. Take a look at surveys, take a look at download counters, do some browsing in bookshops... there is quite an amount of evidence that suggests JSF is used more than Wicket, which I think was the original point.

I could have mentioned btw that Seam has quite a stellar growth as well and that it's predominantly although certainly not strictly used with JSF, but I didn't since I would like to support the Seam - JSF connection with numbers instead of just saying it.

>Huh? Hurt who?

Weren't you the "Wicket nazi"? *lol*

>Interestingly, this DZone link (and thread) was all about JSP and JavaScript

I can't help to spot the word "JSF" in the title, so it might not be that strange that it attracts JSF users.

>Isn't it great to see the wide array of choices and healthy "ecosystem" in Java web-framework land :P Go GWT ! Go Spring MVC !

Yes and no. Choice is good, but fragmentation isn't. The optimal situation is probably a nice balance between a few innovative frameworks. Currently I just see too much fragmentation and a bunch of obscure frameworks that sometimes make a lot of noise in the blogosphere but are barely used.

>> Choice is good, but fragmentation isn't

Interesting that you should say that. Let's take a look at the various JSF component libraries a project can choose (of which only one is production ready for JSF 2.0):

RichFaces
ICEfaces
PrimeFaces
OpenFaces
BindowsFaces
GMaps4JSF
WebGalileo Faces
Trinidad
QuipuKit
NetAdvantage for JSF
Tomahawk
Scales
Oracle ADF
AUI Faces
SmartFaces

Let me guess. This falls under the "choice is good" category. Right? :P

>Let me guess. This falls under the "choice is good" category. Right? :P

Either you *really* don't understand or you're trying to make some joke that's just lost on me.

Anyway, those are indeed COMPONENT LIBRARIES. Not frameworks, but component libraries. As a framework, you want as many of those as possible, since the idea is to simply use them together. Compare this with classes on the JVM. Of course you want as many classes as possible to be available, and of course I can use classes from one library together with those from another library.

So all of those contribute to the healthy eco-system that is JSF. I can use components from RichFaces, OpenFaces, Tomahawk and my own personal library perfectly on one page.

> (of which only one is production ready):

??? They are pretty much all production ready, thank you.

Now there is maybe only one production ready for JSF *2.0*, but the way you make it sound is like "Only 1 library has ever been created for JSF 2.0, see how bad that is", while in reality it's "One JSF 2.0 library is already completely production ready, while many others are currently in production".

Whoa, whoa, whoa. Too many words. Ah the "ecosystem". A simple "yes" would have sufficed as an answer :)

I don't fancy the prospect of entering into support contracts with multiple "COMPONENT LIBRARY" vendors, but I guess anything is possible if you try hard enough.

P.S. I did mention JSF 2.0 in my post. Can't you read !? :P

>I don't fancy the prospect of entering into support contracts with multiple "COMPONENT LIBRARY" vendors, but I guess anything is possible if you try hard enough.

If a single support contract is what you want, maybe you should use .NET? For your typical Wicket setup I guess if you want to have everything covered by a support contract then you need to have contracts for the OS (Linux, Windows), the JVM (Oracle, IBM), Wicket (Apache has support contracts for Wicket? Well I guess someone has) and you're lying if your projects don't use some amount of third party Java libs, probably Apache commons or stuff like that. You're looking at 3 support contracts already.

With JSF, I could choose say Oracle and have the OS, JVM and all EE stuff like JSF, JPA, JTA, EJB covered by a single support contract! Hah! I WIN! :P

Of course, normally you don't want a support contract for every little tidbit. Our clients typically want a support contract for the AS, which is typically JBoss AS, which covers core JSF, JPA, etc and as a nice bonus RichFaces as well. For additional Java libs and JSF components we typically don't have support contracts, and our clients don't really ask for it. Should problems arise then the source is all ours and we provide patches ourselves. This is basically the same as we support our own code.

Of course, you don't -have- to get components from multiple libraries if support contracts are so important for you (but if support is important, Wicket would be the very last on my list, so I don't really understand why you think bringing up this argument wins you anything). In practice, tons of people are perfectly happy to operate without expensive support contracts that in the end don't always help a lot anyway.

>P.S. I did mention JSF 2.0 in my post. Can't you read !? :P

I can, but it said JSF 3.0 first. This was silly, since JSF 3.0 hasn't been released yet. Then you changed it into .NET libraries, which I just didn't understand the relevance of. Who cares whether there is only 1 production ready library for .NET (which incidentally I don't think is even true). Then you changed it again into just JSF (which I quoted) and now it's JSF 2.0.

I'm not sure what you're trying to accomplish here, but you have a strange sense of humor ;)

>> I can, but it said JSF 3.0 first. This was silly,
>> since JSF 3.0 hasn't been released yet. Then
>> you changed it into .NET libraries, which I just
>> didn't understand the relevance of. Who cares
>> whether there is only 1 production ready library
>> for .NET (which incidentally I don't think is even true).
>> Then you changed it again into just JSF (which I quoted)
>> and now it's JSF 2.0.

Wow. Okay, calm down Henk. Yes, you WIN. Feel better now?

P.S. A small correction to the list of JSF component libraries I posted earlier. "NetAdvantage for JSF" needs to be taken off the list because it was "retired" in Dec 2009. No doubt because the JSF "ecosystem" was so healthy that evolutionary "survival of the fittest" mechanisms kicked in.

http://www.infragistics.com/archived-jsf-retired.aspx

>Wow. Okay, calm down Henk. Yes, you WIN. Feel better now?

I'm completely over the moon! Brilliant! :D

>P.S. A small correction to the list of JSF component libraries I posted earlier. "NetAdvantage for JSF" needs to be taken off the list because it was "retired" in Dec 2009. No doubt because the JSF "ecosystem" was so healthy that evolutionary "survival of the fittest" mechanisms kicked in.

Exactly. Nobody forces you to work on a project forever. You know what? I once created this java library, with lots of cool classes. After some time I just didn't feel to work on it anymore. Family life, work, other stuff, so I just stopped working on it and thus 'retired' it. Does this indicate that the Java "ecosystem" may not be healthy? Does it?

Wicket is dying, I think it will join apache attic soon. Competitor of JSF is GWT. wicket, stripes, webwork are projects with tiny communities compared to JSF and open source projects fail when they don't have enough users. We've switched from Wicket to JSF 2.0 and can't be happier, development speed is lightning fast now. It is so much better compared to JSF 1.2 which people including me didn't like very much but JSF 2.0 is just great.

I did notice it too that I hear more and more stories of people switching from Wicket to JSF. The thing is that Wicket might be nice, but there is barely anyone who actually uses it. This means companies have a much harder job of hiring people, especially since they don't buy into the argument that one can learn Wicket in 2 days, or whatever the number of days Wicket fans use.

The killer feature that JSF has going for it, is that it functions as an open platform upon which anyone can innovate. This means lots and lots of component libraries and extensions have been created for JSF and continue to be created.