{{ !articles[0].partner.isSponsoringArticle ? "Platinum" : "Portal" }} Partner

ZK vs. GWT : Server-Centric Matters!


[ Jeff Liu is an engineer with Potix Corporation, who are creators of the ZK framework ]


  1. Abstract
  2. Server-Centric and Client-Centric
    • Where Applications Run
  3. Server and Client Centric Ajax Frameworks in Practice: ZK and GWT
  4. ZK vs. GWT in Action : Google Maps Locator
    • ZK (1 File, 36 Lines of Code)
    • GWT (5 Files, 190 Lines of Code)
    • DWR (2 Files, 77 Lines of Code)
  5. ZK vs. GWT in Action 2 : Data-binding
    • ZK (1 File, 39 Lines of Code)
    • GWT (4 Files, 200 Lines of code)
  6. ZK vs. GWT in Action 3 : Live data
    • ZK (1 File, 15 Lines of Code)
    • GWT (I Don Even Want to Code It)
  7. ZK Anywhere
    • What about the devices without browsers?
    • ZK on Java Phones
    • ZK on Google Android
  8. Conclusion
    • Right Tool for the Right Job


1. Abstract

On Feb 18th, 2005 Jesse James Garrett first introduced the term “AJAX” in his essay “Ajax: A New Approach to Web Applications.” Since then, Ajax has become a very popular topic in web application development communities. In the past 2 years, numerous Ajax frameworks have been built for the development community. These frameworks vary from pure JavaScript frameworks, such as Yahoo! UI (YUI), to Flash based ones such as Adobe AIR (Adobe Integrated Runtime). But, one important concept is often ignored by the media and general audience: are the frameworks server-centric or client-centric? This article attempts to clarify some misconception with real ZK and GWT examples.


2. Server-Centric and Client-Centric

Where Applications Run:

In short, the main difference between server-centric and client-centric is where the application runs. In a server-centric framework, the application is hosted on the application server and all processing is done on the server. The client browser is only used for data presentation.

In contrast, applications that do all of their processing on the client side, such as GWT, use JavaScript running in the client browser.


Figure 1 - Server-Centric vs. Client-Centric

3. Server and Client Centric Ajax Frameworks in Practice: ZK and GWT

ZK and GWT bring a similar mantra to Java developers - developing Ajax applications using Java rather than JavaScript. To developers who rely on Java as their tool of choice, both frameworks offer a great escape from the JavaScript nightmare.


At the first glance, developers will consider that these 2 frameworks are similar: both allow the developer to use Java, and they both, support AJAX user interface components. Probe a little more deeply into the mechanism behind both frameworks and you will see that ZK and GWT work in an entirely different fashion. Generally GWT compiles Java code into JavaScript allowing the application to run in the client browser rather than on the server's. Applications built of GWT interact with the server only when data retrieval is necessary. ZK framework uses a different approach from GWT: the application runs on the server and ZK takes care of the presentation layer.



To Know more how ZK works as a server-centric framework, refer to the following:

4. ZK vs. GWT in Action : Google Maps Locator

In the following section a simple Google Maps Locator application will be implemented by ZK and GWT in order to demonstrate the difference between the frameworks. Assuming that you are coding a Google Maps Locator for a client, the requirements might contain:

  1. An UI with a text input field, a button and a Google map.
  2. When user clicks the button the text in the textbox will be used as a keyword to find the latitude, longitude and description for that location.
  3. Displaying the location on the Google Map and display the description as an Info Window.

Figure.2 - Google Maps Locator


Let us assume you have already implemented a magical Java class which is called ocator.?It will take a string as input and return the required information. The only work left is implementing the UI and data retrieval parts. Let see code from both frameworks in real action.

ZK (1 File, 36 Lines of Code)


<?xml version="1.0" encoding="utf-8"?>
<script src="http://maps.google.com/maps?file=api&v=2&key=KEY"
import com.macroselfian.gps.Locator;
public void locate(){
String location = tb.getValue();
double[] pos = Locator.locate(location);
mymap.panTo(pos[0], pos[1]);
<div align="center">
<separator spacing="50px" />
<label value="Macroselfian Google Map Locator"/>
<hbox width="600px">
<textbox width="550px" id="tb"/>
<button width="50px" onClick="locate();" label="Search"/>
<gmaps id="mymap" zoom="16" ...>
<ginfo id="ginfo"/>

GWT (5 Files, 190 Lines of Code)

Client Side Files:

  1. Map.java ?The main application class
  2. LocationGenerator.java ?The interface for RPC.
  3. LocationGeneratorAsync.java- The interface for RPC.
  4. LocatorData.java ?The data wrapper class for passing data from server.

Server Side Files:

  1. LocationGeneratorImpl.java ?The data provider class in server side.

Code Snippet:


?br />public class Map implements EntryPoint {
public void onModuleLoad() {
?br /> mapWidget = new GMap2Widget("400", "600");
gmaps = mapWidget.getGmap();
VerticalPanel vPanel = new VerticalPanel();
HorizontalPanel hPanel = new HorizontalPanel();

public class ClickListenerImpl implements ClickListener{
public void onClick(Widget widget) {
LocationGeneratorAsync async =
async.locate(location.getText(), new LocationCallback());

public class LocationCallback implements AsyncCallback {
public void onFailure(Throwable error) {

public void onSuccess(Object resp) {
LocatorData data = (LocatorData)resp;
double lat = data.getLat();
double lng= data.getLng();
String inf = data.getInfo();
Label info = new Label(inf);
GLatLng pos = new GLatLng(lat,lng);


public interface LocationGenerator extends RemoteService {
public static final String SERVICE_URI = "/locationgenerator";
public static class Util {
public static LocationGeneratorAsync getInstance() {
LocationGeneratorAsync instance =
ServiceDefTarget target = (ServiceDefTarget) instance;
return instance;
public LocatorData locate(String location);


public interface LocationGeneratorAsync {
public void locate(String location, AsyncCallback callback);


public class LocatorData implements IsSerializable {
private double _lng;
private double _lat;
private String _info;
private String _title;

public LocatorData(double lat, double lng, String info,? {
_lng = lng;
_lat = lat;
_info = info;
_title = title;
?br />}


public class LocationGeneratorImpl extends RemoteServiceServlet 
implements LocationGenerator {
public LocatorData locate(String location) {
com.macroselfian.gps.Locator locator =
new com.macroselfian.gps.Locator(location);
LocatorData data = new
return data;


Using the ZK framework, the component state is maintained by the server. One of the advantages of server-centric applications is that data retrieval and business logic processing are straight-forward. Since the component states are maintained on the server side, retrieving data or processing business logic requests require no extra work.

In contrast, a GWT-RPC call is required when GWT applications needs data from the server. In Map.java, async.locate(? is called when onClick is trigged, then a callback object, LocationCallback is required to process the returned data. If you have any JavaScript programming experience, you will soon find out that it is very similar to calling XMLHttpRequest functions in JavaScript. Up to this point you have probably figured out that by using ZK server-centric approach, developers don have to make an RPC call and handle the returned data manually.

DWR (2 Files, 77 Lines of Code)

Here is a sample code for achieve the same functionality by another client-centric framework, DWR.


<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"


<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 


<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<script type="text/javascript" src="dwr/engine.js"></script>
<script type="text/javascript" src="dwr/util.js"></script>
<script type='text/javascript' src="dwr/interface/locator.js"> </script>
<script src="http://maps.google.com/maps?file=api&v=2" type="text/javascript"></script>
<script type="text/javascript" src="http://www.google.com/jsapi?key=ABCDEFG"></script>
<script language="javascript" >

var lng, lat, map;

function goto(location){
locator.locate(location, callBackLat);

function callBackLat(data){
lat = data[0];
lng = data[1];

function load(){
if (GBrowserIsCompatible()) {
var level = 16;
map = new GMap2(document.getElementById("map_canvas"));
map.setCenter(new GLatLng(lat, lng), level);
map.addControl(new GSmallMapControl());
map.addControl(new GMapTypeControl());
var point = new GLatLng(lat,lng);

function setGmarker(){
var point = new GLatLng(lat,lng);
map.addOverlay(new GMarker(point));

function setGinfo(){
locator.getInfo(location, callBackGinfo);

function callBackGinfo(data){
var point = new GLatLng(lat,lng);
span_element = document.createElement("span");
txt_node = document.createTextNode(data);

<input id="location" type="textbox" onchange="goto(this.value);" />
<div id="map_canvas" style="width: 500px; height: 300px"></div>


Both GWT and DWR use the client-centric approach, but DWR is quite different from GWT. Compared to GWT, DWR requires less codes. However, as a result of its flexibility, developers have to handle the browser dependency issues. In short, DWR only builds the ridge?between the client and the server.


5. ZK vs. GWT in Action 2 : Data-binding

Every developer will encounter this in his/her career, displaying master and detail problem. For example, there is list of names when the user clicks on one of names; the details behind the name need to be displayed in the details panel. ZK comes with a very neat solution for this task: annotation data-binding. For more information about ZK annotation data-binding, please refer to Y-Grid Support Drag-Drop and DataBinding.

To achieve this task in GWT, developers need to make an RPC call, find which cell in the grid which needs updating and so on. It is not a bad idea, but you have to do all that work by yourself.


ZK (1 File, 39 Lines of Code)


<?init class="org.zkforge.yuiext.zkplus.databind.AnnotateDataBinderInit" ?> 
<window xmlns:y="http://www.zkoss.org/2007/yui" width="500px">
<zscript src="Person.zs"/>
<y:grid height="200px" model="@{persons}" selectedItem="@{selected}">
<y:column label="First Name"/>
<y:column label="Last Name"/>
<y:column label="Full Name"/>
<y:row self="@{each=person}">
<y:label value="@{person.firstName}"/>
<y:label value="@{person.lastName}"/>
<y:label value="@{person.fullName}"/>
<!-- show the detail of the selected person -->
<textbox value="@{selected.firstName}"/>
<textbox value="@{selected.lastName}"/>
<label value="@{selected.fullName}"/>
//init each person
setupPerson(Person person, int j) {
person.setFirstName("First "+j);
person.setLastName("Last "+j);
//prepare the example persons List
int count = 30;
List persons = new ArrayList();
for(int j= 0; j < count; ++j) {
Person personx = new Person();
selected = personx;
setupPerson(personx, j);


GWT (4 Files, 200 Lines of code)

Client Side Code:

  1. FooExt.java ?The main application class
  2. DataSourceGenerator.java ?The interface for RPC.
  3. DataSourceGeneratorAsync.java- The interface for RPC.

Server Side Code:

  1. DataSourceGeneratorImpl.java ?The actual data provider class in server side.

Code Snippet:


package test.gwtExt.client;
import com.google.gwt.core.client.EntryPoint;
?br />public class FooExt implements EntryPoint {

?br />
public void onModuleLoad() {
_response = new Label();
_first = new TextBox();
_first.addChangeListener(new OnTextChangeListenerImpl());
_last = new TextBox();
_last.addChangeListener(new OnTextChangeListenerImpl());
DataSourceGeneratorAsync async =
async.getData(new DataCallback());

public class DataCallback implements AsyncCallback {

public void onFailure(Throwable error) {

public void onSuccess(Object resp) {
Object[][] data = (Object[][])resp;

public void createGrid(Object[][] data){

MemoryProxy proxy = new MemoryProxy(data);
_recordDef = new RecordDef(
new FieldDef[]{
new StringFieldDef("first"),
new StringFieldDef("last"),
new StringFieldDef("full")

ArrayReader reader = new ArrayReader(_recordDef);

Store store = new Store(proxy, reader);
ColumnModel columnModel = new ColumnModel(new ColumnConfig[]{
new ColumnConfig() {
setHeader("First Name");
new ColumnConfig() {
setHeader("Last Name");
new ColumnConfig(){
setHeader("Full Name");
setRenderer(new Renderer(){
public String render(?;

_grid = new Grid("grid-example1", "460px", "300px", store, ?;
_grid.addGridRowListener(new RowClickListener());


public class RowClickListener implements GridRowListener{

public void onRowClick(Grid grid, int rowIndex, EventObject e) {
FieldDef[] fs = _recordDef.getFields();
Record record = grid.getStore().getAt(rowIndex);
_selectedRow = rowIndex;

?br />

public class OnTextChangeListenerImpl implements ChangeListener {
public void onChange(Widget widget) {
* TODO: Modify data in server side by RPC
TextBox target = (TextBox)widget;
Record r = _grid.getStore().getAt(_selectedRow);
r.set("first", target.getText());
}else if(target.getName().equals("last")){


public interface DataSourceGenerator extends RemoteService {
public static final String SERVICE_URI = "/datasourcegenerator";
public static class Util {
public static DataSourceGeneratorAsync getInstance() {
DataSourceGeneratorAsync instance =
ServiceDefTarget target = (ServiceDefTarget) instance;
target.setServiceEntryPoint(GWT.getModuleBaseURL() + SERVICE_URI);
return instance;
public String[][] getData();


public interface DataSourceGeneratorAsync {
public void getData(AsyncCallback callback);


public class DataSourceGeneratorImpl extends RemoteServiceServlet 

implements DataSourceGenerator {
public String[][] getData() {
org.zkoss.demo.DataSource ds = new org.zkoss.demo.DataSource();
return ds.getData();

6. ZK vs. GWT in Action 3 : Live data

One of the most frustrating problems for web application developers is displaying large amounts of data without the latency of data loading. ZK comes out with a very neat solution to this problem, live data (load-on-demand). For more information about ZK live data, refer to How to realize the idea of live data in a Grid.


ZK (1 File, 15 Lines of Code)


<window xmlns:y="http://www.zkoss.org/2007/yui" title="Y-Grid Live Data"  
width="200px" border="normal">
String[] data = new String[200];
for(int j=0; j < data.length; ++j) {
data[j] = "option "+j;
ListModel strset = new SimpleListModel(data);
<y:grid height="200px" model="${strset}">
<y:column label="options"/>

GWT (I Don Ever Want to Code It)

The concept is like this: add a listener for the grid bodyscroll event then, when the body is scrolled, get the roper?data from server by GWT-RPC. After that parse the data and add the data into the grid model and then finally, call the grid render method. If you know a better way to accomplish this task, please contact me.


7. ZK Anywhere

What about the devices without browsers?

Due to the iPhone phenomenon, some Ajax solutions support smart phones with browsers. But, what about 1.8 billion Java phones which do not come with such resources (computing power, memory, browser, etc.) that iPhone provides? The server-centric/thin-client approach by ZK brings benefits to those resource constrained devices. Your client devices will not be limited to robust ones with browser. With ZK, you can run your Web applications anywhere.


ZK on Java Phones

Figure 3 - ZK on Java Phone

More articles about ZK Mobile



ZK on Google Adroid

Figure 4 - ZK on Android

More aritcles about ZK Android



8. Conclusion

Right Tool for the Right Job

In the process of collecting information for this article, I found out that there are thousands of articles comparing Ajax frameworks. Many of them are trying to convince the reader that one framework is a etter?choice than others, thus treating the Ajax framework market as a Zero-Sum Game. I personally see it from a different point of view. After having seen both the server-centric and client-centric frameworks, making a comparison for them is like comparing apples to oranges. Both frameworks come with the initiative of developing Ajax applications with less efforts, but they take an entirely different approach to it.


To me, both of them are great tools to use. The real question is what kind of problem are you trying to solve?

Find the right tool for the right job. For heavy data access applications and projects that require a higher level of security, I prefer the server-centric approach. If the application requires fancy client side actions and less server requests, the client-centric approach could be my choice.

{{ tag }}, {{tag}},

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}
{{ parent.authors[0].realName || parent.author}}

{{ parent.authors[0].tagline || parent.tagline }}

{{ parent.views }} ViewsClicks