Adam Bien's Weblog
To JSF Or Not To JSF ...This Is The Question - or Why vi is Not Enough
- Java Server Faces 1.2 are already shipped with every Java EE 5 server - so before you are choosing a more esotheric framework, you should at least evaluate JSF.
- JSF are component based - the development model is event-driven and similar to Swing
- A backend object (backing bean) receives the events (just a method)
- Bi-directional, declarative Data Binding can be used to synchronize the view-components with the backing bean
- The backing bean runs on the server - it can access e.g. the EJB 3.0 per Reference. "Fat Client" programming model is possible :-). This is a huge advantage. No value objects, client objects etc. are required.
- Model View Presenter / Model View Controller patterns are easy to implement. The presenters / controllers can be even shared with Swing apps (in theory - in practice the views are too different).
- Convenient data conversion for the common types (e.g. from String to int) already happens behind the scenes.
- Validation support is already built in.
- Navigation / Page Flow are provided and standardized.
- Visual tool support for JSF is outstanding. Most of the tools are free e.g. Netbeans 6.1, Oracle JDeveloper, Eclipse with Plugins (e.g. Visual Page Designer in WTP 2.0). Some tools (e.g. Netbeans) provide visual support for page flows.
- There are already many JSF component providers - many have AJAX support, and are opensource.
JSF programming with good tool support can be very productive (in my opinion - unbeatable). So it is absolutely possible to build from scratch a CRUD app in three minutes (with nice table - sorting included) - without hacking. In case a given JSF provider fully covers your customer's requirements - it's the best choice. Some extensions like Shale or Tiles, help you better structuring your application / page flow. However I would only use them if necessary (every jar increases the complexity...- and makes the deployment harder).
Nevertheless JSF 1.2 has also a "dark side":
- The amount of XML-configuration is considerable (therefore tools are absolutely needed - vi, even emacs are not enough :-))
- Building custom components requires some deeper knowledge - it is not so simple, as it could be.
- Every request is a POST request - you will need some workarounds for bookmarking etc.
- For more sophisticated applications - you will need to understand the "6 phases" - this can take a day of experimentation to fully understand it.
- You will still need JavaScript / AJAX expertise, regardless how good your framework is.
- Customizing the look and feel of the visual components, can be time-consuming. Go with the default if possible.
- The whole component tree is cached on the server in memory - you should plan some performance tests to verify the requirements. In general the performance is o.k.
Posted at 10:14AM Jun 25, 2008 by Adam Bien in Java EE 5 Architectures And Idioms | Kommentare[12]
[my tweets] 
Rss My book: Real World Java EE - Rethinking Best Practices
The answer is clear: STAY away from JSF: same complexity as EJB 1.x or 2.x: 15 people on earth can understand this complexity.
$Billions lost in failed project.
Look at the number of extra jars you need (so non standard, not supported, ...) to add to your classpath to do simple things.
And then this Ajax integration which is going the opposite way of JSF: In Ajax, the client in in Control. In JSF, the server is in control and every mouse click is a server trip (hint: your server will die on load!!!)
The comestic fix for JSF in EE 6 will not solve the issue, so stay aswy from JSF
Gesendet von 213.200.214.135 am June 25, 2008 at 03:55 PM CEST #
213.200.214.135,
you have strong opinion:
"...same complexity as EJB 1.x or 2.x: 15 people on earth can understand this complexity...."
This is a good idea for a blog entry - stay tuned.
"Look at the number of extra jars you need (so non standard, not supported, ...) to add to your classpath to do simple things."
Download e.g. Netbeans ...and just start.
"In Ajax, the client in in Control. In JSF, the server is in control and every mouse click is a server trip (hint: your server will die on load!!!)"
I have to disagree:
1. Server can DIE because of AJAX load as well (either because of comet, or polling)
2. You can provide as much AJAX into your client as you want to.
"The comestic fix for JSF in EE 6 will not solve the issue, so stay aswy from JSF"
Why not? More arguments please. I did already some projects with JSF - and the customer was happy (so they were successful in my eyes).
thanks for your (strong) opinion. What you would suggest to use for web development?
adam
Gesendet von Adam Bien am June 25, 2008 at 04:00 PM CEST #
To me JSF, and all so-called "component frameworks" like ASP.NET etc. - are simply completly weird idea. First, HTML IS FUNDAMENTALLY NOT COMPONENT oriented. Let's face it. There might be gazillion JSF frameworks, gazillion components, but:
* Did You ever tried to mix components for example from IceFaces with ADF? Whole idea of "components" is You are able to reuse it. But it simply doesn't work in the case of JSF... As simple as this. Once You start with given implementation of JSF, You'll have to live with it forever. For Bad and Good (and do not expect many good days).
* Who the hell invented the idea that DEVELOPER, PROGRAMMER/whatever should WORK ON UI?!?!? On every nontrivial WEB application there ware web designer who did the magic (to do serious work, You'll have to hire WebDeveloper anyway - just to overcome varius limitations. But, working with "other's" code happens to MUCH more expensive, if even possible, than with Yours). Then You have things done exactly You needed, with pixel perfect accuracy, and amazing effects. Nothing that could be achieved with Out-of-the box "components". Show me publicly facing nontrivial application??? Ask first Web develoer - what he or she thinks about "components"...
* So called "event" frameworks, like JSF and ASP.NET are fundamentally flawed. HTML/HTTP is not event oriented!
* Much more momentum are gaining simple and powerful frameworks like RoR, Grails and all this stuff. They do right things and far, far faster than ASP.NET or JSF. Are simple, natural, lightweight and just works. And are simply MVC.
Just my $0.3.
Artur
Gesendet von Artur Karazniewicz am June 25, 2008 at 06:27 PM CEST #
In this order: Grails, Stripes, Struts action 2, wicket.
They are all better options than JSF: simpler, perform better, easier to understand and debug, easier to integrate with Ajax technologies. Everyone that has tested both agree on this point.
To make a quick and dirty check, search the web for "jsf sucks" and "grails sucks" and compare results.
You think that he has a strong opinion - well, I want my 6 months of my life struggling with JSF back.
Gesendet von Ignacio Coloma am June 25, 2008 at 11:12 PM CEST #
I'm using SEAM 2.0 (with rich faces, ejb 3.0 and jboss 4.2). This is basic JSF components with AJAX capabilities (rich faces) and a very powerful container model (SEAM + ejb3).
At home I am beta testing the same configuration with groovy as main language for development - since now, no major issues.
All I can say is that the development on this platform is a thrill and it's fantastically easy to use. Just put JBoss Tools on your eclipse, new seam project and you're good to go.
BM
Gesendet von BM am June 26, 2008 at 10:38 AM CEST #
1) Implement a Restful, stateless, thin Server-Architecture with your lean serverside framework of choice (preferably empowered by the industry standard Spring directly or on a higher level with Grails)
2) Decide between GWT and Flex for your frontend technology.
3) Enjoy the prevented complexity and ease of use.
Gesendet von Sakuraba am June 26, 2008 at 12:17 PM CEST #
In fact, the author was correct. Sometimes, specially in a corporate environment, the null flexibility of a JSF (add even portlet) approach is desirable. Even more so when the developers aren't stellar
Gesendet von Jose Noheda am June 26, 2008 at 04:29 PM CEST #
I agree with the 1st poster. Stay away from JSF. When all you have is a hammer (server side java) everything looks like a nail (web development). JSF is a joke because it tries to make programmers feel like they are developing a desktop app (GWT is just as bad). But guess what, ITS NOT. Its a web app with stateless HTTP protocol. In the time someone takes to learn all the JSF intricacies they could have learned how to program for the web and learn a little HTML and JS to be proficient in web app development.
Another idea (like EJB 1/2) that in theory seems good but utimately leads to more failed and unmaintable projects than KISS
Gesendet von Darryl Stoflet am June 26, 2008 at 11:00 PM CEST #
I agree with your post. It depends. I've done some rather small but very successful JSF projects.
I am looking forward to JSF 2. The current standard lacks some important features as you pointed out in your article.
The biggest advantage of JSF are the ready to use components that are available from apache.org and others.
I also think that every JSF developer should have a close look at JBoss Seam, especially if you want to combine JSF with EJB 3.
Spring Web Flow 2.0 might be another interesting option to improve JSF productivity.
In the future, JSF 2.0 with Seam (or Spring Web Flow 2) and a powerful IDE (like Netbeans or Eclipse) should dramatically improve web developer productivity with JSF. If it's enough to stop people moving to other solutions like Grails, well be interesting to see.
Gesendet von Markus Jais am June 27, 2008 at 01:04 PM CEST #
som our experiencies
Advantages:
- component based UI (easy to read, implement and fix)
- transparent project structure
- reusable GUI patterns (better like html hell)
- wide funcionality inside components
- diverse tag libs the can be used on the implementation
- possibility to work with GUI components through their object representation
- custom components possibility to implement
- absolut trivial AJAX integration
- good rapid development
- visual tools with css avaliable
- philosophy like an Desktop GUI development
Gesendet von jason am July 01, 2008 at 06:16 PM CEST #
Disadvantages:
- not all works what have to work
- compatibility problems
- page design limits
- not very easy for JSF newbies
- disaster for css designer
- no templating within
- only post links
- no cacheing framework
- bad documentation
- weblinks and back button doesnt work :/
Gesendet von jason am July 01, 2008 at 06:17 PM CEST #
I opted for Struts2 after trying to implement a prototype with JSF.
For me, an action based approach is _much_ simpler as the component based one. It is a web framework, I do not want to build a desktop application. The only really impressive component based application I have ever seen is DabbleDB, developed with Seaside.
For me, component based approach is well suited for admin panels or smaller intranet applications. Web applications that try to feel like a desktop app. But this is only a small number of overall web applications. So JSF is no all purpose tool for me. Struts2 is :-)
Gesendet von piero am July 27, 2008 at 06:35 PM CEST #