I'm a software architect specializing in web-based solutions with Ajax frameworks such as Ext, Dojo, Prototype, Scriptaculous and JQuery on the front end and Spring and Hibernate as middleware. I also have experience with .NET solutions, Web Services and many more aspects of software development. Chris has posted 2 posts at DZone. You can read more from them at their website. View Full User Profile

JavaServer Faces vs. Ajax Frameworks - Why Ajax is Better and Not Just Hype

08.20.2009
| 18127 views |
  • submit to reddit
Today I am looking into a JavaServer Faces application that I am having to make a few changes to. I didn't write it and the developer who did write it, wishes he had chosen another technology. I've done several projects with JavaServer "Feces" so far, I really hoped I wouldn't see it again, but yet, here it stands in front of me. I loathe everything to do with the overhyped "Struts killer" of old. JSF did indeed kill Struts fairly effectively, but for reasons involving pure hype and not because it was a better technology.

I'm not advocating Struts either as a solution mind you. I worked on Struts projects for years and enjoyed them. It was the best Web framework at the time, which was several years ago now. If you're starting a new project, save yourself some time and don't choose Struts, and for God's sake, stay away from JSF.

The problems with JSF are numerous. The JSF lifecylce is a horrible bastardization that is suppose to resemble something like the ASP.NET side of development. matter of fact, most of the purpose of JSF was to compete with ASP.NET in the drag and drop world of GUI development and it failed miserably. It is not a pleasure to work with, nor does it work in the "drag and drop" world as advertised and I won't even get into the problems with Ajax-enabled JSF components. I mean you really need to steer clear of those unless you enjoy being punished on a daily basis. JSF doesn't perform well, it isn't easy to get up to speed on, it is horribly inflated and overhyped and once you start working in it, you get bored and frustrated very quickly and want to throw it out the door. One of the biggest issues I had was that I bought into it about 5 years ago and started trying to use Ajax-enabled JSF components and trying to use multiple third party providers at the same time. This was a big mistake. In the end you get a page, loaded with junk that doesn't work because multiple versions of the same Ajax libraries are clashing with each other or worse yet, javascript functions and variables get overwritten magically from one component or another.

These days I prefer to use an Ajax frameworks like Dojo, Ext, Scriptaculous, JQuery..etc, to build my presentation tier. Most developers will say the same thing about these frameworks I say about JSF, it is all hype, confusing and doesn't perform well. In order to respond to these claims, I am going to justify my preference for these frameworks in just a few simple sentences. Feel free to start a debate with me if you don't like my stance on JSF, but after 4 years of on and off dealing with it, I'm sure you can't say anything that will change my mind.

Reasons to use an Ajax Framework over JSF

  1. Ajax promotes a clear separation between your page technology and your server-side technology. My applications can use anything on the backend, Spring/Hibernate, .Net, Python, PHP, Perl, Ruby...you name it. This is because I only transport JSON data to and from the server. No JSP, JSF, ASP or any of that sort.
  2. Clear separation of roles. In a larger shop, you can have Java developers and Ajax developers. They don't have to bridge the gap between each other's jobs unless they want to. They only need to understand JSON, which is easy and much lighter than XML.
  3. You don't have to worry about writing one language with another. Remember in the servlet days when we wrote HTML with Java, in JSP there was often scriptlet code intermingled with HTML, much like in PHP and ASP. My Ajax code only contains components from the libraries I am working with and I have never had a problem with two of them clashing. JSF is a disaster when it comes to components playing nice on the same page, especially when they are Ajax components.
  4. I have finer grain control over the look and feel of my application. Dojo and Ext widgets are very customizable, much moreso than primitive looking JSF components. Sure, you can write your own JSF components, but I'd rather used a canned Ajax one that works better.
  5. The Ajax framework components are extremely rich. In Ext, I have a grid that sorts, searches, filters and all that and a bag of chips. In JSF, I couldn't get half of that functionality, and a majority of the time, operations happen on the server and the page refreshes.I don't want to reload the entire page...just the data.
  6. Ajax components and refreshing the page results in a repainting of redundant data. With an Ajax framework, most of the time, you build a component and only interchange the data using JSON. Why do I want to continuously refresh a page or section of a page to repaint the component, when in Ajax the component is ready and just needs data.
  7. I can test without having the application server running. If I want to test a piece of code or a snippet, I don't have to wait until it is deployed. I have browser right there to try it out.
  8. I can asynchronously load several components at one time. Let me see you add 3 grids to a JSF page and update all three grids at different times. Here is a little tip, you'll jump through hoops making it work and you'll more than likely refresh your page 3 times and it will perform like poo. With Ajax, I refresh all 3 grids at the same time and the page will never flash. Matter of fact, the first one will load and give the user some data to look at while the second one is loading it's data.
  9. I generally avoid statements like "it's really cool", when referring to a framework, but in this case it fits. For example, last night I wanted a login form to appear on a page that is asynchronously loading and times out. The backend server was whacked and the page continued to load data, getting login problems when the server came back up, the login form appeared over the top of the screen, I logged in and the page was as it was when the server went down and I never left the screen. The only data that was exchanged, was the actual data the page needed for display. No unecessary HTML being transported over the wire.
  10. I don't need your stinkin faces-config.xml. Why would I? I don't need your navigation rules, your validator, your locale information. I already have your locale, navigation is now non-linear ( I bring up objects when I need them...destroy them when I don't) I use built in validation with my widgets. What if the user's browser doesn't support Javascript, you ask? Well, then they need to upgrade. It's been over 8 years since browsers started heavily relying on Javascript. If you don't have Javascript enabled, then you aren't seeing anything on the Web anymore anyway.

If I haven't convinced you that Ajax frameworks are better than JSF, let me know and I will make sure you get to write JSF on a project for a few months and we'll see how you feel afterward. If you still don't agree with me, I'll buy you lunch.

From http://www.chrislhardin.com/

Published at DZone with permission of its author, Chris Hardin.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Bozhidar Bozhanov replied on Thu, 2009/08/20 - 2:15am

Well, your statement is wrong from the very beginning. It is not hard to google 'JSF ajax' (or something of the sort), and stumble upon wonderful frameworks like RichFaces or PrimeFaces. There are ajaxified and ajaxifying jsf components. Then all of your arguments go nowhere. I've worked with RichFaces for sometime, and it is really state of the art. You use ajax with writing no javascript whatsoever. Validators can use your model objects directly (with Hibernate-validation), so - automatic ajax validation. And so on, and so forth.

So better go check those frameworks ;)

Maxence Warzecha replied on Thu, 2009/08/20 - 3:03am in response to: Bozhidar Bozhanov

I think you use bad work saying "ajax".

I do not use any "jsf-ajaxifying" but there is RichFaces

http://www.jboss.org/richfaces

RichFaces is a component library for JSF and an advanced framework for easily integrating AJAX capabilities into business applications.

  • 100+ AJAX enabled components in two libraries
    • a4j: page centric AJAX controls
    • rich: self contained, ready to use components
  • Whole set of JSF benefits while working with AJAX
  • Skinnability mechanism
  • Component Development Kit (CDK)
  • Dynamic resources handling
  • Testing facilities for components, actions, listeners, and pages
  • Broad cross-browser support
  • Large and active community

I think you should review article by explain what you mean by "ajax" cause some if not all of your arguments work for Adobe Flex for example so...

Max

Alessandro Santini replied on Thu, 2009/08/20 - 2:57am

Chris, I guess you owe me one lunch.

With this I do not want to imply that JSF is the best web framework around: I second some of your criticisms, particularly as to the lack of a proper IDE integration (Microsoft world has one IDE, the Java world in contrast has many and still without agreed standards as to visual web beans); I could also add many others (postback management still sucks, rendering of non-faces responses has still many grey areas, etc.) but that is out of scope in this moment.

What I do not agree with is dismissing JSF as "all hype". JSF is a framework that has been around for a while, perhaps is not the best performing, perhaps it is not the easiest to tackle. There are some good points for which I still consider JSF an option when choosing a web technology for a project:

  • It is, like it or not, part of the JEE5 stack;
  • Being part of the JEE5 stack implies that I will find on the market skilled developers with understanding of JSF (excluding widget sets that may change) 
  • There are a plethora of AJAX-enabled JSF libraries; AFAIK not a standard one yet, but will come on time;
  • Facelets has phased out most of the cumbersomeness as to writing JSP pages with JSF;
  • Not every web project needs Ajax;
  • Accessible applications and AJAX are a no go.

Ajax frameworks are good, I like them very much too. But JSF is a web framework that can prove suitable in many occasion, and dismissing it too quickly can be, in my opinion, a bit shortsighted.

 Ciao,

 Alessandro

Nicolas Bousquet replied on Thu, 2009/08/20 - 3:06am

I agree with chrislhardin, JSF is not a good solution.

JSF technology is just a complexified struts. It's only interest compared to struts would be the libraries like RichFace that Boshidar Boshanov talk about. Still Struts is much more used than JSF.

On a architectural design JSF is not very good. Complicated, the GUI is rendered on the server, consuming ressources and limiting the overall performance and the number of clients that can be served. It need in fact a bunch of session data and need a good bandwidth.

If you use heavily JSF ajax components performance is very poor even when testing your application with only one or two users.

As I see it, the client GUI code should remain on the client side. At the start of the application or as needed, GUI code, pictures and all are download by the client. After that, with the browser cache and all, the only thing that will be downloaded by the client would be data.

In fact, you can do it in javascript. With today web browsers it's fast and responsive. You web server can deal with many more clients, because just the data is sended to the client.

For the javascript technology i would not choose to directly work with javascript through. I would choose GWT, making all my client side code in java, like i was coding with SWING.

But hey in fact with GWT, plus additionnal GUI API like Smart GWT, and you have SWING on the browser. You can do exactly what you do in SWING applications. Listeners, windows, really interractive applications and all.

And all that with high performance and strict seperation between GUI and Model.

JSF is old technology... It just a struts replacement. But now we don't want struts like apps... We want applications like Google Docs. Just try to do it in JSF richface !


 

Eugene Kisly replied on Thu, 2009/08/20 - 3:34am

Looks like you didn't use modern jsf frameworks, for example richfaces, icefaces, openfaces

They can do most of yours points. 

Casper Bang replied on Thu, 2009/08/20 - 5:55am

Nice article, JSF is indeed an over complicated beast, obviously not designed by people who actually have to work with it.

Martin Wildam replied on Thu, 2009/08/20 - 7:06am

foudres wrote:

> As I see it, the client GUI code
> should remain on the client side.

In some cases a "real"/thick client really makes sense, isn't it? ;-)

Casper Bang wrote:
> JSF is indeed an over complicated beast

I also found/find it complicated but on the other hand I have WYSIWYG design of the GUI and the page flow in my IDE which is helpful. When we start talking about over-complicating things: I consider application servers also as overcomplicated for smaller applications. I really miss something really simple and straightforward framework that is just core Java + one library (the framework). For instance if you have a server application that needs some configuration which you would like to offer over the web (as many network printers do) I don't like the need of an application server. BTW: I wonder why nobody is mentioning Wicket - I found that also quite nice (but did not use it for real yet). Yes, it uses page reloads - but you can also do AJAX with it. But something more important: Accessibility and true REST - how is it implemented with frameworks like GWT? How can I send a link to a friend, if my application url never changes after loading the application because all data only loaded over the background javascripts?

Liyu Wang replied on Thu, 2009/08/20 - 8:21am

So What's the point? Does Tomcat complicated? do you use it? Or you handcraft a webserver? What do you suggest to use on the server side? JSF has hype, but not totally, use JSF + Facelet + Richface, I can easily define the template, navigation is good, and JSF allows me to overwrite the modules (like navigation, render, validation, component), also Richface provide a lot AJAX features, check or , . I think you should spend sometime really "polish" yourself or find another job that doesn't require JSF, rant doesn't help.

Ed Burns replied on Thu, 2009/08/20 - 9:58am

As spec lead for JSF obviously my comments are biased so I'll simply say two things. 1. Please try JSF 2.0. It's a lot easier, especially for Ajax 2. For a list of real world sites using JSF, including Adidas, Apple, Garmin, RiteAid, Credit Suisse, etc, please see http://wiki.java.net/bin/view/Projects/RealWorldJSFLinks Thanks for helping to promote JSF!

Shay Shmeltzer replied on Thu, 2009/08/20 - 11:20am

When was the last time you looked into current JSF technologies?

Take for example ADF Faces (which had partial page rendering for 5 years) - in the new version that has been out for almost a year now the table component does all the things you mention with built-in Ajax capabilities for streaming the data to the client.

With a set of over a 150 other components and the integration with JDeveloper you do get the Microsoft type of drag and drop development  - see for example:

http://download.oracle.com/otn_hosted_doc/jdeveloper/11gdemos/visualDeclarative/visualDeclarative.htm

Alexander Ashitkin replied on Thu, 2009/08/20 - 1:46pm

guys, you can say any good thing about jsf just to feel yourself better. everything what's necessary today - is a simple navigation framework like spring mvc, flex + good JS library, like ExtJS. It will be simplier, more attractive and run faster. Was you ever trying to customize richfaces component? it's easier to eat lemon with ass. The main reason it's still alive - it's a part of JEE.

Liyu Wang replied on Thu, 2009/08/20 - 2:17pm in response to: Alexander Ashitkin

the features I need from the framework is Navigation (Rule based), security (flexible Authorization), memory/concurrent management (especially for AJAX client), bi-direction form/data mapping, support conversation and easy development/deployment model.

Marc Stock replied on Thu, 2009/08/20 - 4:57pm

Chris, you are my hero!  If there were such a thing as a Java President, you would have my vote.  Finally, I don't know if you owe Alessandro a free lunch but if you do, I will buy you one to make up for it.  Keep up the good work!

 Java Server Feces...classic!

Walter Bogaardt replied on Thu, 2009/08/20 - 6:20pm

JSF makes you write a lot if your writing components. But as other posters have stated RicheFaces and others provide some nice simplicity for Rich web interfaces. I do know the pain of JSF, and it hasn't been that stellar of an environment and does have its pitfalls in terms of testability. I also agree years later and where is that simple drag and drop ide and easier way to manage JFS navigation and outcomes, yeash.

Peter Thomas replied on Fri, 2009/08/21 - 2:06am

Couple of things in the article I disagree with:

JSF did indeed kill Struts fairly effectively

 because other frameworks had more to do with it, and:

These days I prefer to use an Ajax frameworks like Dojo, Ext, Scriptaculous, JQuery..etc, to build my presentation tier.

IMHO, that is just going from the frying pan into the fire.  I really don't understand why people think re-inventing MVC in javascript is a good idea, perhaps it is borne out of the recent fascination with REST and polyglot programming etc.  But try hacking javascript for a while to develop serious user interfaces and you will understand.  Maybe after a couple of years yes, but as of now you can't convince me that the tooling support and the innumerable script-kiddie ways you can trip yourself up with JavaScript lends itself well to enterprise development projects.  And I've tried, really.  Hopefully I'll get time to blog about this point more in detail.

That said, I agree wholeheartedly with the spirit of the article.  JSF sucks, and really, saying that 2.0 solves everything doesn't cut it.  Except for resume-driven projects who like to be on the bleeding edge, it will be a while before JSF 2.0 would be mature enough for adoption.

Anyway, please see this blog post for my take on this:

http://ptrthomas.wordpress.com/2009/05/15/jsf-sucks/

 

Jose Maria Arranz replied on Fri, 2009/08/21 - 2:25am in response to: Peter Thomas

@Peter Thomas: But try hacking javascript for a while to develop serious user interfaces and you will understand

I fully agree, I can't understand why some people like to lose strong OOP, compiler checking, multiple file granularity, "Find Usages" feature of IDEs, myriads of Java libraries, a JVM running at speed of light, data centers with tons of computing resources...

The title of this article is wrong "AJAX frameworks" should be "AJAX based client centric frameworks", server centric frameworks can be AJAX intensive too and can push complex JavaScript to the client to avoid server request when visual changes don't require new data.

In my opinion "life in server is easier" ... with the right tool, JSF is not the only player in the server centric space. Peter has his own tool in mind and I have another  :)

I think the future will be server centric and client centric intermixed, this is not possible with JSF but there are more options.

And if you go for mobile web JavaScript intensive frameworks are not (today) an option, may be in a  future...

 

Nicolas Bousquet replied on Fri, 2009/08/21 - 7:01am in response to: Jose Maria Arranz

"But try hacking javascript for a while to develop serious user interfaces and you will understand.  Maybe after a couple of years yes, but as of now you can't convince me that the tooling support and the innumerable script-kiddie ways you can trip yourself up with JavaScript lends itself well to enterprise development projects."


"I fully agree, I can't understand why some people like to lose strong OOP, compiler checking, multiple file granularity, "Find Usages" feature of IDEs, myriads of Java libraries, a JVM running at speed of light, data centers with tons of computing resources..."

"> As I see it, the client GUI code
> should remain on the client side.

In some cases a "real"/thick client really makes sense, isn't it? ;-)"

 

To these 3 points. Just use GWT with some extensions (like Smart GWT) You hava static checking by the compiler, your can use your classic java environement developpement. You can develop your GUI like if it was a classic GUI in SWING, SWT, .NET... With listeners, responsive UI and all.

If you go for the "heavy" database approach where business code is in the database as procedures, then you use expose them as web service from your database server and can even forget your J2EE application sever.

Otherwise, your java code is just published as web service that you call from javascript. No less, no more.

Just try google Doc, and try to do it with JSF richface...

iIf you don't want HTML/jascript, go for Flex. But dont use a technology with a a stack of 10 or 20 library, each trying to correct design error of the one behind. Don't use a technology that still need page refresh (even partial). Don't use a templating engine that is just for make some HTML.

Use a framework that allow you to think at higher lvl. 

Just try with JSF/RichFace to make a multi window application. Allowing you to open as much window you want in the client side, Showing dozen of view at the same time. Keep them independant. And try to use the listener mechanism so that you when your GUI model is updated, all part of the GUI are update, without the need of the trick to specificaly specify the dynamic zone.

 JSF + richface, is old technology. It's the old PHP design (HTML with templates), with some special tags with embedded AJAX. It's good for a web site. Not for a web app, that in fact should be an heavy client GUI technology but use a browser only for deployment purposes.

We shall not think about javascript or HTML, or template anymore when designing a web application.

 

 

Peter Thomas replied on Fri, 2009/08/21 - 8:01am in response to: Nicolas Bousquet

To these 3 points. Just use GWT with some extensions (like Smart GWT) You hava static checking by the compiler, your can use your classic java environement developpement. You can develop your GUI like if it was a classic GUI in SWING, SWT, .NET... With listeners, responsive UI and all.

Personally I did explore GWT.  I would strongly recommend it if you really *really* want to avoid server-side trips as far as possible.  Yes with GWT you can work in Java and there is this amazing Java --> JavaScript conversion step that happens.  But that amazing approach comes at a price IMO, some quirks and leaky abstractions if you will.

So when it comes to front-ending server-side business logic (and e.g. lazy-loaded-by-default Hibernate / JPA entities) with GWT, you need to be aware of what you may be getting into:

http://ptrthomas.wordpress.com/2008/09/04/wicket-and-gwt-compared-with-code/

Otherwise, your java code is just published as web service that you call from javascript. No less, no more. 

Yeah right.  You make it sound sooo easy.

Exposing REST / WS services is today the easiest thing in the world, just slap an annotation on your class and you are done.

So tell me now:

  • who has to do the hard work of creating the UI ?  Look back on the development projects you have done.  I would say 80% of the effort goes into the UI trying to get the look and feel, alignment etc. exactly how the %&*#$ users demand it.
  • for a complex UI you have to maintain the state on the client now right ?  Do you feel it is easier now than doing it on the server ?
  • what about security?  do you authenticate every single "stateless" request ? how do you do it ?

I would recommend this "server-side services" approach for a user-interface *only* in the case when you really have to support multiple UI technologies at the same time, e.g. Flex and JS and Swing etc.

Nicolas Bousquet replied on Fri, 2009/08/21 - 11:23am in response to: Peter Thomas

who has to do the hard work of creating the UI ?  Look back on the development projects you have done.  I would say 80% of the effort goes into the UI trying to get the look and feel, alignment etc. exactly how the %&*#$ users demand it.

This never changes.

"for a complex UI you have to maintain the state on the client now right ?  Do you feel it is easier now than doing it on the server ?"

So what, it's just POJO compiled to javascript by GWT.  The interrest here is if i have many client, i can keep a lot of things in the client UI and still not consume any memory on the server. No need for session replication, my application is clusterisable from the beginning.

 "what about security?  do you authenticate every single "stateless" request ? how do you do it ?"

 Of course, public web services always need authentification.

Wal Rus replied on Fri, 2009/08/21 - 1:20pm in response to: Ed Burns

>Burns: Please try JSF 2.0. It's a lot easier
Hm... :) this sounds a lot like the old "Please try ejb 2.0" argument :). No, thanks! I'll wait for the JSF 3.0. Well, may be not me.
The JSF model seems awfully wrong for rich client apps: I concur with Chris's belief that role separation is important. There are, of course, stars in the programming field that can see through html/css/javascript/java layers of the app and build a cohesive UI, but there are very few of that caliber. You need to take more factors into account when settling on an approach to particular problem.


 You need to consider a typical career span of a programmer. Because it's short and rarely sufficient to master all the technologies that you(JSF) just threw into the mix. And by the time someone does get suficciently eficient they don't want to do it anymore (it's hard!!! and there are better choices).


 The argument of being an industry standard does not hold water for the very same reason. You can have a lot of people with JSF on their resumes, but do all of them know JSF well enough?


 In my many years of programming I had heard numerous times 'it's the standard' argument, last time regarding maven :) When time came to actually hire someone nobody of the candidates knew maven and more senior people just wanted to stay away from it :) (Complex!)


 So, JSF 2.0? I don't think so. But it may be just me getting old.

Max Katz replied on Fri, 2009/08/21 - 1:48pm

This feels like 2004 all over again.. instead of JSF vs Struts.. it's now JSF vs Ajax... :)

Seb Cha replied on Sat, 2009/08/22 - 8:10pm in response to: Max Katz

The GWT framework is just a javascript applet. There is nothing new in creating heavy weight UI, with windows, panel, and stuff.

So, what has changed since 1998 ? How can GWT success where AWT failed ? IMO this is just a question of browser capabilities ...

On day i will try to embbed Eclipse RCP in an applet ...

Sheng Gu replied on Fri, 2009/08/28 - 4:24pm in response to: Wal Rus

>>Burns: Please try JSF 2.0. It's a lot easier
>wal_rus: Hm... :) this sounds a lot like the old "Please try ejb 2.0" argument :). No, thanks! I'll wait for the JSF 3.0. >Well, may be not me.

I often read the same coments as you wrote. Do you think Windows 95 was developed based on Windows 3.1 or on DOS? EJB3 looks likeWindows 95, while EJB2 looks like Windows 3.1.  This is methodogy of software developments.

 Maybe, you are still using DOS and waiting for Windows 777?

Ted Goddard replied on Tue, 2009/09/01 - 10:40am

Let me see you add 3 grids to a JSF page and update all three grids at different times.
Add three dataTables to an ICEfaces page, and only the parts of the tables that have changed will be updated; you can have this for free without exposing a JSON network API to hackers.

Wal Rus replied on Thu, 2009/09/03 - 12:49am in response to: Sheng Gu

Well, it does not mean that everyone has to jump on the bandwagon of JSF2.0 at the same time, just as some people skipped to Win 95 or NT, or, having tried both, switched to Linux or MacOS. It's the matter of choice that individual opinions help make. It's not that a technology should not have a chance, it's about having everyone decide for himself how much time one should invest into it given the flaws that were outlined, and people's threshold is much different. Some may see JSF as a perfect solution. And while I am perfectly fine with JSP 2.1 I think JSF is yet to show a ROI. It might get there one day, but will it be JSF 2.0? Given the flaws outlined in the post, many of which I second, it's unlikely, IMO. With Flex, SWT, Air and other RCP frameworks JSF better show something of greater value for me to consider it, because it's not just java. When you build a GUI it's more about nice looks which is all CSS, HTML, JavaScript and so forth. Can you imagine the level of synchronization of effort between GUI programmers and back-end programmers to see a product through it's life cycle? The interdependence would just be awfully expensive as it spills over delivery deadlines. Just looking at the turn that it took with ajax change seems dramatic. It became ever more complex, and you'll need to persuade GUI developers to actually consider it. Why would a developer choose JSF over Flex, Air, Ajax where you can build your GUI with mock objects, without ever needing to run your stuff on a server?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.