JSF... My post-JavaOne impressions.
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 at JavaRanch as but one indicator 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.
JSF... Your post-JavaOne mis-impressions.
Re: JSF... My post-JavaOne impressions.
Re: JSF... My post-JavaOne impressions.
To the last poster - the whole point of JSF plus AJAX is that you -wouldn't- have to maintain the javascript - it would be fully managed by the JSF component itself. Your own JSPs would not contain -any- javascript; it would be rendered by the component at page generation time.
Regarding components being a good thing about JSF: I guess that's a matter of taste. I think it's clear that component based development is more attractive than class library/javadoc development for a large number of users, so JSF makes the java platform and web programming more accessible to these developers. Personally I think configuring things like tables and calendars to appear in pages more convenient using property sheets and customizers rather than reading taglib docs or javadocs or any of the other ways you configure reusable web functionality with other frameworks. But clearly I'm biased - I'm working on a JSF tool.
Re: JSF... My post-JavaOne impressions.
Re: JSF... My post-JavaOne impressions.
Swing GUI builders took years to mature
Re: JSF... My post-JavaOne impressions.
Re: JSF... My post-JavaOne impressions.
Re: JSF... My post-JavaOne impressions.
Re: JSF... My post-JavaOne impressions.
Re: JSF... My post-JavaOne impressions.
Fast forward many months to today (10-21-2005) when the product release is done and "on CD". How do I feel about JSF now having gone through a full product development and release cycle? I feel that my initial concerns were justified. It is basically not ready for prime time in my opinion. In order for a framework like this to work "well" you need a solid IDE to support WYSIWYG development. Most important, you need a good IDE to do enhancements and bug fixes efficiently (i.e. when someone other than the original developer is working on the pages).
JSF, in my opinion, is a total non starter for decent web application development. Components? Big deal. Nothing you can't accomplish clener using STRUTS. Is the goal of being able to "easily target multiple display device types" a value that JSF brings to the table? No. Not any more than any other framework.
I have read up on Tapestry and I have to say, "the Tapestry folks get it". Let's face it, web applications today are HTML centric. You can hide the HTML in components and fool yourself that you're building a "real desktop app". At the end of the day I think anyone that's been developing commercial grade software for a while would agree that JSF in its current state without a GOOD open source IDE (or any good IDEs for that matter) is just not ready for prime time. You should also expect to spend a lot more time performing bug fixes, debugging, enhancements, etc.
And, did someone mention AJAX in the same sentence as JSF? I want to see the clean application that uses the two technologies to perform a simple table update.
Re: JSF... My post-JavaOne impressions.
Re: JSF... My post-JavaOne impressions.
Re: JSF... My post-JavaOne impressions.
Regarding tapestry, the beauty of it is that it is essentially marked up HTML. This makes layout and structures easy to see / view.
As I said in my earlier post, the tutorials seemed "ok" and reading up on JSF it seemed "ok" but the real insight came when building a large application with the technology. This is when it was really clear that I would not personally choose JSF for a future project until it was "fully baked" (i.e. as easy to use as straight HTML/jsp). There was really no benefit for me using JSF. In fact, if anything, it slowed the development down and made bug fixing take much longer than necessary.
Now I will qualify it with the fact that we used myfaces and not a commercial implementation. Therefore I don't know if I'm skewed by the tools I used to build this. However, the fact that you don't control all aspects of an input box, don't control layout of boxes and tables as you are used to coding in HTML, etc, makes it very difficult. You end up either using the layout and coding that is part of the framework you use or have to rewrite some of the rendering to your taste when you uncover some odd constructs.
I think one of the more interesting questions to ask is, "Do we really want/need Swing behavior in web apps?" I think we want some of the characteristics that desktop apps have but don't need to model after "Swing" to achieve this unless the tools are there to support it.