RSS RSS feed | Atom Atom feed

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.



Re: JSF... My post-JavaOne impressions.

Hey, glad you enjoyed the smackdown. It was a lot of fun from the stage too :-) If you couldn't tell, I'm not too sold on the "it's component based, so it must be better" sales pitch either. At the end of the day you're building HTML text, not a Swing GUI.

JSF... Your post-JavaOne mis-impressions.

As an avid Struts developer, I must admit that AT FIRST (listening to all the SUN hype), I was quite turned OFF by the whole idea of a component-based web view layer that creeped into the model layer with listeners, etc. HOWEVER, having read much more about JSF (from other sources, including SUN), I have discovered that JSF as a whole is actually quite strong. Unlike Struts, JSF offers developers TWO, yes that's right, TWO different programming models for the Model layer that links to the View layer: 1) The big SUN response to .NET component-based model layer that is sort of like the "code behind" the View layer: where we have listeners, actual code representing and manipulating the visual components. 2) The Struts-friendly value-based model layer that doesn't have any link to the View layer at all and just does the business Struts Actions would usually do. Unfortunately, SUN is strongly advertising option 1. However, both options are part of the JSF standard and it's really up to the developer to choose. Personally, I find that JSF used with option 2 is much easier and quicker to develop than the Struts equivalent, with about 80% less XML content to maintain thanks to J2SE 5.0 annotations. Also, your entire Model layer is composed of pure POJOs that do not extend or implement JSF-specific classes, unlike all the Struts Actions. This brings the application a lot closer to implementing a true MVC architecture instead of a web-only with Struts alternative. Oh, coding textually with option 2 is also a piece of cake and I would rather sell my soul than use the drag & drop option 1 that creates all that "code behind" clutter in all my Model classes. Just my 2cents. Avoid the SUN bandwagon, go read up on the actual JSF standard and start using something that really is more like a second generation Struts that fixes many of the weaknesses inherent in the Struts framework and make your app easier to develop and maintain!!!

Re: JSF... My post-JavaOne impressions.

I think people are wanting web apps to do too much. Or just things beyond their working domain. AJAX and the amount of people gushing at the seems over it is a prime example. Have you looked at the mess that is javascript to use AJAX? I wouldn't want to maintain it. If you want desktop application like features, then write/use a desktop app. There are some nice things about JSF but the bad outweighs the good.

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.

Genrates crap code? that's why I always code in binary. These compilers just produce crappy bit formations. Anyway, JSF is the answer to ASP.Net. It eliminates having to play around with HTML and worrying about a mess of JSP tags. Give it a try using a real RAD tool for a real web application before knocking it.

Re: JSF... My post-JavaOne impressions.

To Tom - Ok, show me a good RAD tool and I'll try it. I've yet to see one. JSC is good for small applications that don't do much. Start building a real web application and you'll find youself digging through that crap code more than you want. Then you'll start wondering why you didn't just write all that code yourself and it wouldn't be crap anymore. I feel that I have the right to knock JSF all I want. I've given it more of a chance than a lot of people. I wrote one of the first REAL tutorials on JSF a week after 1.0 went final. I've tried several JSF RAD tools and none of them come close to something really useful in the real world. They are only good for JSF proponants to demo simple drag and drop web app creation features at people who don't know any better and think it's "cool". Real developers don't use GUI builders anyway, don't you know that. ;)

Swing GUI builders took years to mature

But they are very close to VB levels, maybe the next version of Netbeans would finally reach the VB ease of use. So JSC is still very young and made a lot of mistakes in its first version. I'll bet its second version still won't rock but they are working in that way. I think both posters about AJAX are right, JSF will hide AJAX complexity but it will make AJAX related bugs a nightmare to debug since you will have to understand the generated code yourself. So JSF is nice and AJAX is nice and JSC is nice, none of them are great or a silver bullet and I don't think anyone claimed they are. I think Sun is just offering decent solutions for somethings people are asking for. They are offering migration paths for Struts users but they aren't claiming JSF is better, its an apples/oranges thing... JSF has one real advantage of being a JCP standard with multiple implementations, struts has an advantage of a bigger user base (experience with the technology). People should stop arguing about such things, the true argument is Swing vs. SWT ;)

Re: JSF... My post-JavaOne impressions.

I am working a personal business project, a green field project, and suspect that learning JSF will be more productive than learning Struts (I've read up on both), as JSF should produce a "cleaner", more consistent solution without all the unmaintainable struts config spagetti. I shall look into Shale too. I have an idea to use AJAX to view and control a camera remotely from any browser. The AJAX shall also provide control over other devices. Is the recommendation of this forum that one should use a JSF AJAX component, or use raw AJAX javascript embedded in a JSF application (and is there a snag with that approach)? Kind regards, Jim

Re: JSF... My post-JavaOne impressions.

Unmaintainable struts config spaghetti? As opposed to the unmaintainable jsf config spaghetti in faces-config.xml? I don't see much of a difference. I personally have never had a problem maintaining the struts config, and I don't suspect it would be that different from having to maintain faces-config.

Re: JSF... My post-JavaOne impressions.

Jason, excellent point. However, with Struts, the problem is that you have to update more files per change no, it is harder to maintain in this respect. But I am speaking as a newbie, so accept my reasoning may be faulty, but would be interested in any thoughts anyone has about the relative ease of making changes, which is easier, JSF or Struts?

Re: JSF... My post-JavaOne impressions.

"Updating more files per change" has never been a maintenance issue. Most maintenance problems come from unreadable codes and bad design in my 10 years coding exp. I haven't tested JSF, but in most case more automatically generated codes will cause more maintenance issue.

Re: JSF... My post-JavaOne impressions.

Hello. Ok, so it's months after the initial post so my apologies for this being very late. However, I just completed a project that used JSF. The decision to use JSF was made before I joined the company. I read up on JSF and worked with a couple tutorials to get a feel for what it really was. My initial impression was that it was not the right tool for the job. That said, I was new and voiced my concern but the word came down "that the decision to use JSF is made and we are sticking with it." Understand also that nobody on the project had built with JSF before.

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.

Guys, Thanks for your replies, please keep your insights coming! I've read up a bit on JSF, and also produced a webpage with it, and I too am beginning to have concerns that it doesn't feel right, I get the impression that it is a devil if a component doesn't quite work the way it is intended. Additionally, Tiles is probably superior at code reuse. The fact that Struts is open source is in its favour too. Tapestry sounds interesting, does this have IDE support that is any good? For now my instinct is to use Struts on my project, my mind is changed. Thanks for the feedback.

Re: JSF... My post-JavaOne impressions.

So which IDE were you using for your JSF development? And which components?

Re: JSF... My post-JavaOne impressions.

I hand crafted the JSF, rather than use an IDE, I was only putting together a trivial demo, nothing intricate or ambitious. Now I brushing up on my Struts :) Talking of which, have you anyone any experience with open source Struts IDE's, or maybe something like "myEclipse"?

Re: JSF... My post-JavaOne impressions.

I have not used an IDE for JSF. Primarily because the only reasonable solution I saw at the beginning of the project was cost prohibitive.

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.

Re: JSF... My post-JavaOne impressions.

For those interested in the true power J2SE 5.0, JSF and EJB 3.0 have to offer... JBoss offers us a glimpse in the J2EE 5.0 world with Seam: http://www.jboss.com/products/seam The glue that implicitly binds all the MVC layers together.

JSF... Your post-JavaOne mis-impressions.

As an avid Struts developer, I must admit that AT FIRST (listening to all the SUN hype), I was quite turned OFF by the whole idea of a component-based web view layer that creeped into the model layer with listeners, etc. HOWEVER, having read much more about JSF (from other sources, including SUN), I have discovered that JSF as a whole is actually quite strong. Unlike Struts, JSF offers developers TWO, yes that's right, TWO different programming models for the Model layer that links to the View layer: 1) The big SUN response to .NET component-based model layer that is sort of like the "code behind" the View layer: where we have listeners, actual code representing and manipulating the visual components. 2) The Struts-friendly value-based model layer that doesn't have any link to the View layer at all and just does the business Struts Actions would usually do. Unfortunately, SUN is strongly advertising option 1. However, both options are part of the JSF standard and it's really up to the developer to choose. Personally, I find that JSF used with option 2 is much easier and quicker to develop than the Struts equivalent, with about 80% less XML content to maintain thanks to J2SE 5.0 annotations. Also, your entire Model layer is composed of pure POJOs that do not extend or implement JSF-specific classes, unlike all the Struts Actions. This brings the application a lot closer to implementing a true MVC architecture instead of a web-only with Struts alternative. Oh, coding textually with option 2 is also a piece of cake and I would rather sell my soul than use the drag & drop option 1 that creates all that "code behind" clutter in all my Model classes. Just my 2cents. Avoid the SUN bandwagon, go read up on the actual JSF standard and start using something that really is more like a second generation Struts that fixes many of the weaknesses inherent in the Struts framework and make your app easier to develop and maintain!!!

Re: JSF... My post-JavaOne impressions.

If you're dismissing JSF, and you've used it -without- a tool, you're really missing a lot of the value proposition of JSF. With component technology, you're not reading TLD docs, you're assembling an app from prebuilt debugged components, that you can customize right there in your tool with WYSIWYG behavior and so on.

Re: JSF... My post-JavaOne impressions.

In my experience, WYSIWYG is usually synonymous with code bloat. I may just be old'school with my text editing preference though. =)

JSF for nonbelievers: Clearing the FUD about JSF

http://www-128.ibm.com/developerworks/java/library/j-jsf1/index.html

Re: JSF... My post-JavaOne impressions.

Wow, you guys touting tools, to which tools are you referring? Nitrox, MyEclipse and Exadel are the only ones I know of that support JSF. (Oh, and Sun's JavaStudio Creator, like we're all going to download that and switch off between it and Eclipse). The MyEclipse stuff was buggy as hell just a couple months back. I haven't tried Exadel since their Struts tool always crashed when I tried to edit a large struts-config.xml. And I can't seem to get Nitrox to send me an evaluation license since they got bought by BEA. What I need, and JSF needs I argue, is a free or cheap Eclipse plugin along the lines of Tapestry's Spindle. Get with it. Sun will drag out this JSF thing forever like they did the JSTL (years!!) and you'll never see a great tool in time for when JSF is being EOL'ed for something else in 2-3 years.

Re: JSF... My post-JavaOne impressions.

Re: the developer works article by Hightower: He only makes the case that JSF without WYSIWYG is better than the older frameworks, not that WYSIWYG development with JSF isn't better than without it. Re: tools: The tool I would advocate would be Creator (given that I work on it). It doesn't have to be an either/or decision; use the right tool for the right job. If you limit your options to Eclipse and its plugins you are missing out on a number of facilities available in other tools. But I don't want to start a religious IDE war here. I wanted to make the point that JSF is great for tools, and you can get a lot more productive using JSF with a tool built for it. Good night and good luck.

Add a comment Send a TrackBack