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

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.