To JSF Or Not To JSF ...This Is The Question - or Why vi is Not Enough

  1. 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.
  2. JSF are component based - the development model is event-driven and similar to Swing
    1. A backend object (backing bean) receives the events (just a method)
    2. Bi-directional, declarative Data Binding can be used to synchronize the view-components with the backing bean
    3. 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.
    4. 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).
  3. Convenient data conversion for the common types (e.g. from String to int) already happens behind the scenes.
  4. Validation support is already built in.
  5. Navigation / Page Flow are provided and standardized.
  6. 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.
  7. 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":

  1. The amount of XML-configuration is considerable (therefore tools are absolutely needed - vi, even emacs are not enough :-))
  2. Building custom components requires some deeper knowledge - it is not so simple, as it could be.
  3. Every request is a POST request - you will need some workarounds for bookmarking etc.
  4. For more sophisticated applications - you will need to understand the "6 phases" - this can take a day of experimentation to fully understand it.
  5. You will still need JavaScript / AJAX expertise, regardless how good your framework is.
  6. Customizing the look and feel of the visual components, can be time-consuming. Go with the default if possible.
  7. 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.
So to JSF Or Not To JSF - I'm a consultant - so the answer is clear: "it depends" :-). If you are building a corporate, enterprise application - JSF are just perfect. On the other hand, if you target is the consumer market, you are probably looking for more flexibility (and probably more effort to build the app then). Already looking forward to JSF 2.0 :-).

Comments:

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

Posted by 213.200.214.135 on June 25, 2008 at 05: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

Posted by Adam Bien on June 25, 2008 at 06: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

Posted by Artur Karazniewicz on June 25, 2008 at 08: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.

Posted by Ignacio Coloma on June 26, 2008 at 01:12 AM 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

Posted by BM on June 26, 2008 at 12:38 PM 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.

Posted by Sakuraba on June 26, 2008 at 02: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

Posted by Jose Noheda on June 26, 2008 at 06: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

Posted by Darryl Stoflet on June 27, 2008 at 01:00 AM 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.

Posted by Markus Jais on June 27, 2008 at 03: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

Posted by jason on July 01, 2008 at 08: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 :/

Posted by jason on July 01, 2008 at 08: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 :-)

Posted by piero on July 27, 2008 at 08:35 PM CEST #

Yo hice un proyecto web con Visual JSF que traía el netbeans 6.5.1 y pasé mucho trabajo, porque era mi primer proyecto con JSF, y por la poca flexibilidad que tienen los componentes para poder cambiarle su apariencia. Visual JSF no era bueno, no tenía AJAX support... Y lo quitaron en las siguientes versiones de Netbeans. Más tarde realicé otro proyecto usando la implementación Richfaces de JBOSS y mejoró mucho mi experiencia con JSF 1.2. Richfaces ya tiene soporte ajax para sus componentes. Además, tiene skines para poder cambiarle la apariencia a los componentes, siendo el trabajo con css algo más flexible. Creo que con JSF 2.0 va a mejorar bastante este framework, que sí es cierto es difícil de aprender.

Posted by Alain on November 24, 2010 at 09:20 PM CET #

Post a Comment:
  • HTML Syntax: NOT allowed
...the last 150 posts
...the last 10 comments
License