This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
Let me state upfront that I don't really know all that much about JSF. I'm mainly a Struts guy and have been using it since 2000. That doesn't mean that I'm against trying anything other than Struts; quite the contrary actually. So I recently got back from JavaOne, and many of the sessions I sat through concerned JSF in one way or another, to the point that I think I have at least somewhat of a feel now as to what it's generally about.
The JSF propaganda from Sun was ever present throughout JavaOne. There were a few things they were trying hard to promote, and JSF certainly seemed like one of those things. I went into this with an open mind looking for some answers as to what JSF could do for me. I approached these sessions looking for a compelling reason for me to adopt this technology. I didn't find one I'm sad to say. After sitting through all these sessions, the only thing compelling thing they could say was that it was component based. Uhh, yeah, great. Not that there's anything wrong with a component based approach by any means, but surely it has to have something else going for it that would make it a "must have" for my projects, right?
JSF was developed primarily for RAD. The idea was that the tool vendors would provide the capability to build drag-and-drop web interfaces using their IDE's and JSF. I imagine their goal was to try and make application development VB-like in this regards. Yeah, RAD may turn out a usable application in the short term, but it also turns out completely unmaintainable crap code. Of course, this also limits you to the handful of tools that support JSF. But I digress, this isn't meant to be a rant against RAD-tools. When all is said and done, what we get with JSF is basically Swing for Web apps. That's fine for a desktop app, but I have yet to see anything to convince me that this is just as appropriate for a web app.
AJAX was a big buzzword at JavaOne this year. I sat in several sessions that dealt with the topic, most of them given by Sun staff. If you listened to these evangelists talk, you might come away thinking that the only way to do AJAX in Java was to use JSF. Of course, we all know that this isn't the case.
One of the sessions was a "Web Frameworks Smackdown" that pitted representative of JSF (Ed Burns), Tapestry (Howard M. Lewis Shipp), Webwork (Jason Carreira), Wicket (Eeico Hillenious), and Shale (David Geary) against each other in order to promote their frameworks over the others, as well as an extensive Q&A from the audience. I was quite tempted to ask the Sun JSF rep what he thought would prevent JSF going the way of JDO. There are some striking similarities between JSF and JDO in my mind. You only need to look at the forum traffic here at JavaRanch to give you an idea of how the majority of the community seems to feel about JSF as an app framework, particularly when compared to something like Struts.
Initially I always thought that JSF would be good if it just stuck to the UI. Unfortunately, the people at Sun decided that they wanted to make it an application framework as well. From what I can tell, it doesn't seem all that great as an app framework when there are so many real frameworks that do the job so much better. After listening to the non-JSF speakers at the "Web Frameworks Smackdown", I think that it is the other frameworks that will in fact end up saving JSF from itself. Some of the other frameworks, most notably Shale, will be leveraging JSF for what it is good at, as a UI component, while leaving the framework plumbing to more capable frameworks. I think it is this adoption of JSF by Shale that will lead to a greater acceptance of JSF by the community, an acceptance that I quite frankly don't see happening any other way. Relegate JSF to the UI only, let a real framework handle the rest, and JSF might just thrive.
I came out of the Smackdown with the opinion that there was definitely some good stuff out there in the Web App Framework department. Tapestry, which I have heard nothing but good things about, looks outstanding. Webwork and Wicket, aside from having the most entertaining presenters (along with HMLS of course), look like they are both worth learning more about. The thing I'm most excited about though is Shale. I predict that what we will be seeing quite a bit of in the near future are Shale-based web apps leveraging JSF for the UI with the whole thing sitting on top of Spring. Time will tell of course. [ July 06, 2005: Message edited by: Jason Menard ]
I agree with all that you mentioned about RAD/JSF stuff. But I still feel idea backing the JSF seems to be better than the one behind Struts. I have limited knowledge of Struts but still I feel JSF seems to be similar and at some places much cleaner than Struts. But without a doubt, JSF development does contains some curves and hopefully things will only improve. Somebody rightly mentioned way back in some thread that JSF 4.0 probably is going to be the technology to work on But I still believe if you are planinig to use JSF just for UI, better have a look at other Rich Internet Applications stuff such as Macromedia Flex etc. I did create a demo once using these FLex, Laszlo and it really took no time to learn these technologies, development was as cool as anything and importantly it provides all that you need.
JSF was developed primarily for RAD. The idea was that the tool vendors would provide the capability to build drag-and-drop web interfaces using their IDE's and JSF. I imagine their goal was to try and make application development VB-like in this regards.
You are right and instead of the community creating really good tools that allow you to create JSF based applications really quickly, they threw together, basically, plugins into their current IDE's and made everything proprietary. You mentiond something about JSF looking like JDO? And then there is Java Studio Creator. Ugh! What a disaster. Instead of sun doing the right thing and making a nice full featured IDE they waste valuable time making a JSF ONLY IDE based on Netbeans which is just horendous.
I think it is this adoption of JSF by Tapestry and Shale that will lead to a greater acceptance of JSF by the community, an acceptance that I quite frankly don't see happening any other way. Relegate JSF to the UI only, let a real framework handle the rest, and JSF might just thrive.
I haven't head of Tapestry utalizing JSF on the front end. Even in all the talks of Tapestry 4.0 it's all about how Tapestry uses simple HTML templates. And I hope that doesn't change. Using plain HTML is part of what is attrative about Tapestry to me. If Howard mentioned something about that at JavaOne (or on his blog I haven't read in weeks) then I will be very disappointed and I would consider that move a sell-out move on Howard's part to gain more acceptance of his framework.
My whole thing on JSF is that Sun went in with the right intentions but managed to screw it up. The only reason I haven't moved my current app to something other than JSF is time. But it's what I get for wanting to try the latest and greatest. I am waiting for Tapestry to settle down into it's 4.0 version before really diving back into it. Quite a bit has changed from 3.0 and I would hope that the next versions changes are not quite as drastic. Specifically, I don't care to see JSF stuff in Tapestry.
I think Shale has the right idea but to me it's just something else to learn when it comes out and time will tell as to whether or not that will happen. Interestingly enough, looking at job offers, I don't really see anyone wanting JSF. Struts is still a biggy but for the most part I see companies wanting people to know J2EE. Frameworks are a dime a dozen right now. Knowing J2EE at it's core is the key.
The way I code now days Struts, JSF, Tapestry, it's all front end changes for me. The real work is in classes that just really don't care what is up front. With a few exceptions of course.
I edited the bit about Tapestry leveraging JSF. That was an error on my part.
Joined: Nov 09, 2000
Originally posted by Gregg Bolinger: You mentiond something about JSF looking like JDO?
What I meant by that was in regards to a committee coming together to design something, making it a JSR, and then the community refusing to adopt it despite the fact that it was a "standard". Particularly striking is that both initially required third party vendor-implemented solutions in order to be used.
Instead of sun doing the right thing and making a nice full featured IDE they waste valuable time making a JSF ONLY IDE based on Netbeans which is just horendous.
If you were at JavaOne this year, you would have thought that NetBeans was required to do anything in Java. The way they were pimping NetBeans was truly sickening. [ July 06, 2005: Message edited by: Jason Menard ]
What I meant by that was in regards to a committee coming together to design something, making it a JSF, and then the community refusing to adopt it despite the fact that it was a "standard". Particularly striking is that both initially required third party vendor-implemented solutions in order to be used.
Originally posted by Jason Menard: Not that there's anything wrong with a component based approach by any means, but surely it has to have something else going for it that would make it a "must have" for my projects, right?
The more I've read about and thought about component beans and backing beans the more I hate the ActionForm paradigm that I am so used to. One of the main purposes of our UI and web frameworks is to encapsulate (or provide a facade to) the HTTP gobbleddygook. ActionForms' attempt at this is pretty weak.
David Geary admits in his blog that Tapestry is in his opinion the best framework at the time:
So what's the best Java-based framework available today? It's a very close call, IMO, but I'd have to give the nod to Tapestry at the moment. I really like Tapestry's pure separation of HTML and components and the ability to create custom components without any Java code. That gives it an edge on JSF, which, like Tapestry is one of what I refer to as 3rd generation WAFs, that support components and a server-side event model.
Do I use Tapestry? Heck no. I have a mortgage to pay.
And I'm also really looking forward to Shale. Craig McClanahan sounds very passionate about it and I like that he plans to emulate other successful frameworks rather than reinvent them.
I watched that presentation by Craig. I'd rather hear a presentation on JSF by someone that isn't paid by Sun to promote it. What really made me go is when he was going to demonstrate JSF and used JSC to do so. A tool can make Perl CGI look easy. He kept insisting that you don't need tools to develop JSF apps, which you don't, but then he didn't have the balls to do that himself. HA.
Here is the strangest thing I've ever seen done using JSF. I want to put something in the session. Ready for this?
What the heck is that? Of course, there is another way as well.