First released in March 2004, the server-side component model introduced by JavaServer Faces (JSF) brought the promise of simplifying Web-user interface (UI) development. Then in February 2005, Jesse James Garrett coined the term AJAX (Asynchronous JavaScript and XML) and the simplicity of the JSF server-side component model was overshadowed by a flood of rich UI frameworks with a client-side tilt.

AJAX frameworks (including Dojo, Prototype, and Script.aculo.us) are spurring an evolution in human-computer interaction on the Web. The stale click-and-wait experience once associated with Web applications is no longer acceptable. Users now expect real-time updates and desktop-like functionality coupled with the ubiquitous nature of the Web. Consequently, developers are now stretching the limits of the JavaScript programming model and battling cross-browser idiosyncrasies to mimic desktop functionality over the wire. The result is an escalation in the complexity of Web development – a problem initially resolved by the elegance of the JSF component model. Luckily, JSF has evolved alongside AJAX and is proving not only to be an ideal solution to simplify traditional Web development but also rich Internet application (RIA) development. 

Simplifying AJAX with JSF
The flexibility of the JSF component model (that is, decoupled presentation, state, and behavior) makes it relatively easy to build components that not only render HTML, but also render other markup presentation languages, including DHTML and JavaScript. In their simplest form, AJAX-enabled JSF components use a custom render kit to push a JavaScript and markup presentation to a client browser. In this case, the content rendered not only represents the component, but also provides the necessary functionality in the form of supporting JavaScript objects that initiate XMLHttpRequests (XHR) and handle call backs. These XHR requests, made with JavaScript rendered to the client, are treated as first-class citizens in the JSF life cycle. Tight integration with the JSF life cycle enables JavaScript objects to invoke operations on managed beans, which contain server-side application logic. The beauty of this model lies in its ability to encapsulate the intricacies of AJAX with a simple, cohesive, and reusable component. Moreover, the layer of abstraction afforded by a server-side component model eliminates the need to tinker with JavaScript, DHTML, XML, JSON, or other technologies required to develop RIAs with AJAX. Instead, a single API can be used to develop rich, interactive applications that leverage the underlying technologies that make AJAX possible.

Having a single API for RIA development has many benefits, including encapsulation. But perhaps the most substantial benefit is a solution to the N-to-M problem: an overwhelming number of choices for AJAX frameworks (N), and the fewer, but still substantial number of server technologies (M) used to build AJAX-based RIAs, such as Java, Ruby, .NET, and PHP. According to Ajaxain.com, as of May 22, 2007, there were more than 210 AJAX-based networks in use, and an estimated 1.5 frameworks are added each week. The abundance of possible combinations is daunting. Fortunately, using JSF in combination with AJAX eliminates the guesswork of deciding which AJAX technology to use with which server-side process. In this scenario, a single API delivers not only an AJAX-based presentation, but also a tightly integrated server-side implementation. Moreover, server-side technologies like JSF conform to the Java Enterprise Edition 5 industry standard, and are available through a wide vendor base (including IBM, Oracle, Sun Microsystems, Backbase, ICEsoft, and ILOG).

At a glance, it’s apparent that there are a few good reasons to consider a marriage between JSF and AJAX. However, as in any relationship, it takes significant depth to construct a lasting bond, particularly one that builds on the strengths of each party involved to create a mutually beneficial outcome. It’s easy to develop AJAX-enabled JSF components that operate in isolation or use single threads of execution, but systems that function in this way can be superficial and can serve as a veneer to abstract the complexities of AJAX. A far more daunting task, and one that truly builds on the strengths of the technologies involved, is to build a framework of AJAX-enabled components that go beyond simply delivering an AJAX-enabled presentation. Instead, these components use the JSF-rendering facility to deliver a complete and independent client-side JavaScript component model that compliments the server-side JSF component model.

Distributing Event Handling
One benefit of providing component representation on both the client and server sides is that Java events are triggered and handled on the server, while JavaScript handles events on the client, eliminating many previously required round-trips to the server. The following example illustrates this point. When a user selects a node in a collapsible tree, a tabbed panel or other component on a browser screen is updated and a partial page refresh occurs. Before client-side JavaScript, page updates necessitated a round-trip to the server, even when advanced JSF component sets, such as Apache Trinidad, were used.

However, with a JavaScript representation of the tree, a user selection triggers a client-side event to fire. The event is processed on the client by a listener associated with the tabbed panel, eliminating the need to invoke an operation on the server.

Rendering with a Helping Hand
The ability to balance client- and server-side event handling is not the only advantage gained by a deep and meaningful marriage between AJAX and JSF. With the inclusion of the server in the rendering process, performance becomes another benefit. Unlike JSF, most pure AJAX frameworks, such as Dojo, handle rendering on the client. As a consequence, JavaScript is executed to render a component or widget, and every client component has the ability to re-render itself on the client. Execution also typically includes geometry management and population of a client-side structure, which contains objects to handle the behaviors and states associated with each component. Unfortunately, an immense amount of JavaScript must be executed to initially render a page comprised of multiple components. Excessive JavaScript execution consumes browser- and client-machine resources, fattening the JavaScript thin client. Depending on individual machine configuration, the extra consumption of resources causes performance variability and results in slow initial page rendering. For the end user, the result is a perceived stall in execution that cannot be masked with distractions such as animated images because the invocation of so much JavaScript code consumes too many resources to provide a smooth and meaningful feedback mechanism during page loading.

Using JSF to render the initial presentation substantially lightens the load because, unlike pure JavaScript frameworks, JSF can do initial rendering on the server and then delegate incremental updates to the client or a combination of client- and server-side interactions. One advantage of server-side rendering is that while the server is preparing the presentation for delivery, the browser has ample resources available to provide feedback to the user, indicating that some process is being executed. A more substantial benefit of server-side rendering is the reduction in the JavaScript code necessary to render the page. This results in less client-side resource consumption and ultimately less time to render a page.

To demonstrate this concept, let’s look at the difference in the code execution necessary to render a simple form button in Dojo and an AJAX/JSF framework.

• JavaServer Faces and AJAX for Google Fans
• AJAX, Flash, Silverlight, or JavaFX...