RichFaces – is one of the best JSF libraries offering AJAX support (http://www.jsfmatrix.net/). RichFaces leverages SUN JSF RI for core JSF functionality and Ajax4Jsf toolkit for AJAX wiring. The main RichFaces competitors are .Net and ICEfaces. As opposed to GWT, RichFaces and .Net support traditional traditional two tier web applications development. The two tier web developed follows the MVC model where the View resides on the browser while the Model and Control reside on the server. RichFaces is an Opened Source product developed and supported by Exadel currently owned by RedHat.
- simple steps to upgrade existing JSF applications. The upgrade requires copying three RichFaces jars and adding couple entries to the web.xml descriptor file
- backwards compatibility with JSF legacy pages. The old JSF code will work just fine with RichFaces (kind of like old C code will work with C++). This offers an iterative and low-cost option for adding AJAX support to existing traditional JSF applications. Developers can gradually retrofit sluggish or flickering JSF pages which will benefit the most from introducing AJAX. For example, it is very easy to add AJAX listeners and events handlers to eliminate aggravating page refreshing.
Sample illustrating adding AJAX support to already existing controls:
- Traditional development methodologies built as extensions to the HTML markup language such as ASP, JSP, .NET, and JSF are showing their age. These approaches are more suitable for form-based request/response applications rather than truly Rich UI desktop implementations requiring the complex UI navigation. The fundamental drawback of the JSF/JSP framework is need to implement server components for processing UI data. Whether you use session JSF beans or some other approaches you will need to face a scalability issue and address failover requirements. Storing state on the server works fine for small clusters, but it does not scale well. There is no easy way to replicate session data across large clusters to transparently support failover. Websites that scales to millions of users will probably never use RichFaces due to these fundamental limitations. If you think that changing default options for storing JSF state on the client instead of the server and using exclusively JSF beans request session scope will save you, think again. Even fairly simple desktop style application with JSF state set to client \requires transferring the state data exceeding 300 KB per each submission. While AJAX may come to rescue somewhat this is hardly an optimum way to implement Rich UI.
- GWT and Flex do not need to store any data on the server to provide rich user experience including the complex navigation. Model, View, and Controller (Google calls it Presentation Pattern rather than traditional MVC pattern) are all running on the browser. The UI implementation is completely separated from the server implementation. A server developer does not need to deal with UI logic at all. The communication is completely stateless. The performance and scalability characteristics of client and server implementations are fully separated. The UI developer can concentrate on UI performance i.e. stylesheets optimization, widget lazy loading, and UI model logic. A server developer needs to just take care of the business logic, interfaces with other systems, and persistency. The service developers does not need to know anything about presentation implementation. From his/her perspective, the UI can be implemented in anything as long as incoming and outgoing data complies with message specifications whether it is JSON, plain old XML, or something else.
- There is only one currently available WYSWIG editor for GWT offered by Instantiations. The toolkit is reasonably priced, but I was having problems using this tool when working with complex pages. While many may disagree, the need for WYSWIG editor is not as obvious in case of GWT. After initially struggling a bit, I found it fairly easy to work with GWT panels directly to implement the desired layout. I was using hosted mode to instantaneously test my changes. The only time consuming part of the UI design and development was fixing cross-browser layout problems which required recompiling code. In the hosted mode, the GWT works with the bytecode and uses IE browser compatible container to render the content. In order to test the code on another browser, a developer has to compile the entire which is a very time consuming process.