Sunday, July 19, 2009

GWT vs. RichFaces a different perspective

Posted by Kris Gemborys

The article compares GWT with RichFaces and attempts to provide guidance on which tool is a better fit to meet your needs. Both tools have a similar set of features and a specific set of strengths and weaknesses. However, GWT provides a new approach for implementing UI which allows for complete separation of the presentation implementation from the services implementation. This separation has significant implications on scalability that is often overlooked while simply comparing UI tooling features.

GWT (Google Web Toolkit) – is a toolkit which abstracts javascript language through a sophisticated set of libraries exposed to developers as Java APIs. This set of APIs allow to write rich UI browser-based applications in Java using best OO design and implementation guidelines. The huge bonus is the cross browser compatibility (I found it works most of the time). The libraries have sophisticated support for client state management which significantly reduces complexities associated with writing highly scalable distributed applications. GWT heavily leverages AJAX. All communications with the server are implemented using asynchronous callbacks. GWT is the open source product developed and supported by Google. Google heavily leverages GWT for implementing its SAAS and Cloud computing strategies. All major Google products such as GMail, Wave client, Google Docs, and many others leverage GWT. GWT offers seamless integration with Google App Engine which is the Google’s platform for cloud computing. The main competitors in the same market space are Adobe Flex and Microsoft Silverlight.

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.


RichFaces strengths:

- 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:

<%-- tradition JSF control --%>
<h:selectOneMenu styleClass="combobox" title="Select Payment Method" onchange="setFocusEle(document.forms[0], this);doOnPageRefSubmit(this);" valueChangeListener="#{PaymentBean.onChange}" immediate="true" id="PaymentMethod" value="#{PaymentBean.paymentMethod}">
<f:selectItems value="#{PaymentBean.paymentmethodList}"/>
</h:selectOneMenu>

<%-- AJAX enabled JSF control --%>
<h:selectOneMenu styleClass="combobox" title="Select Payment Method" id="PaymentMethod" value="#{PaymentBean.paymentMethod}">
<f:selectItems value="#{PaymentBean.paymentmethodList}"/>
<a4j:support event="onchange" actionListener="#{PaymentBean.onChange}" ajaxSingle="true" immediate="true" oncomplete="setVisibilityField(data);controlVisibility(document.forms[0], this);">
<f:attribute name="attrName" value="PaymentMethod" />
</a4j:support>
</h:selectOneMenu>

public void changeVisibility(ActionEvent event) {
HtmlAjaxSupport ajaxSupport = (HtmlAjaxSupport)event.getSource();
....
String data = computeChanges();
ajaxSupport.setData(visibilityStr);
}
- replacing legacy menu and popu implementation is also very easy with Richfaces components, all you need is to start using Richfaces tag libraries



RichFaces weakness:

- 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 strengths

- 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.


GWT weakness

- 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.


Conclusion:

Both RichFaces and GWT address similar tooling needs for writing Rich UI applications. However, GWT is on a way in while JSF AJAX is on the way out. In my mind comparing RichFaces to GWT is like comparing Java to C++. RichFaces is the natural evolution from the markup language, JSP, and JSF. RichFaces offers AJAX support and really complete set of controls and APIs. Additionally, it can be easily integrated with proven Enterprise frameworks such as Spring or more recently Seam. On the other hand GWT is a new kid on the block, somewhat similar to what was JAVA in the early days. When JAVA came around it lack a lot of features but quickly grew way beyond simple Applet development tooling. Back then, I remember everyone claiming JAVA is not the right choice for the server development because it does compile code natively so it is not as fast as C++. JSF with AJAX support it is a good choice to give a facelift to existing legacy applications and capitalize on abandon fully-featured tooling, but long-term GWT is probably a better option. RichFaces does not resolve a fundamental problems related to scalability and presentation/server logic separation while GWT does.

References:

No comments:

Post a Comment