Jeff has posted 2 posts at DZone. View Full User Profile

ZK vs. GWT : Server-Centric Matters!

  • submit to reddit

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="" 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. ?The main application class
  2. ?The interface for RPC.
  3. The interface for RPC.

Server Side Code:

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

Code Snippet:

package test.gwtExt.client;
?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();

Published at DZone with permission of its author, Jeff Liu.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Jeff Liu replied on Tue, 2008/06/10 - 9:01pm in response to: Ray Cromwell

Dear Ray

 Thank you for your comment. You really point out some interesting aspects.

About the Google spreadsheet,  ZK team actually is developing a Spreadsheet component now. And, it will be official released soon. In ZK smalltalks, there is a section for this topic.


Again, thank you for the comment :) 

Jeff Liu replied on Tue, 2008/06/10 - 9:06pm in response to: Dino VV

Dear Dino

Could you please share your expertise on GWT? Really like to know the mistakes and misjudgements in this artilce.

 Thank you for your comment. 

Alex Moffat replied on Sun, 2008/06/15 - 11:24am

Ease of development is an interesting axis to compare GWT and ZK but ease of development is not what GWT is all about. Certainly, from my pretty extensive experience, it makes development very easy, but you have to remember what the GWT mission statement says "GWT's mission is to radically improve the web experience for users by enabling developers to use existing Java tools to build no-compromise AJAX for any modern browser.". GWT is about improving the end user experience, not about reducing the number of lines of code the developer has to write. To the extent that improvements to the developer experience benefit the end user then that's good but the point is what the application does and how well it does it, not how easy it is to code. A comparison that talks about the amount of code needed to implement a solution and doesn't talk about the final end user experience of the solution, for instance speed, responsiveness, network load etc. is completely missing the point.

Jeff Liu replied on Mon, 2008/06/16 - 5:25am in response to: Alex Moffat

Hello Alex

 Thank you for the comment.

 From my personal experience, ease of developlment is critical for large enterprise application development.

  1. New team members can easily learn -> Saving training cost
  2. By ZK's databinding approach, developers can directly achieve data-accessing with annotation -> shorten development time
  3. Run in every platform. Write the code once then run in with different ZK client engine -> less portability issueTha

Tony BenBrahim replied on Tue, 2008/06/17 - 8:54pm

I disagree with the title and the whole premise of the article, right down to the conclusion (keeping in mind I have never used ZK, and probably never will, I have heard of Google before :0),but what the hell is ZK and who makes ZK, never would have heard of it if this article was not linked on

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

1. There is nothing inherently more secure with a server-centric approach than with a client centric approach. There are legions of ASP, JSP, JSF and other server side technology applications rife with SQL injection, cross site scripting and upload into executable directory flaws, to name a few. To be fair, a number of AJAX application suffer security flaws. It is not the framework that will make your application more secure, it is the knowledge of the developers.

2. If I am going to put a load on the server with a lot of server requests, I am pretty sure I want to move the UI handling load out to the the user's dual core laptop, not leave it on my server. After all, if I am lucky, the server has eight cores, a thousand users have at least a thousand cores, probably closer to 2000, so why would I not want to distribute all that I can to those thousands of cores. I surely do not want server round trips just to update the look of my UI, I want to save the precious bandwith for data exchanges (enterprise means many users far, very far away from your server, in hotels and airports in third world countries with spotty wireless connections, not always 1Gb or 100Mb to the desktop).

3. Line for line comparaisons are never a good indicator. Having gone from ExtJs+DWR to GWT/GwtExt, I can tell you that ExtJs+DWR results in 1/3 the files and 1/2 the lines compared to GWT, but at least 10 to 20 times the effort. Java on the client + Java on the server, with Eclipse providing type checking, syntax checking, code completion makes the line comparaison worthless. I can put out a hundred lines of deugged working GWT code much faster than 50 lines of Javascript, and I am always positive it will run correctly the first time (can't say the same for Javascript, I could have made a typo and not known about it until I executed the code)

4. Ease of use is a concern. Different technologies on the client and server is a concern. What you fail to mention is that in GWT, the same Java used on the server is used to code the client. I am not sure what you use in ZK, looks like HTML with some proprietary zscript tag and what looks like Java inside (although I suspect it may not quite be Java), does Eclipse do code completion and syntax highlighling for that?

5.Ok, so I agree with "find the right tool for the job". For some classes of application, if you want a rich UI, you should use the full features of the browser, Javascript and the many Javascript UI libraries available. GWT gives you the least painful path to that end. On the server, you should only be concerned with processing data, on a J2EE server, servlets (what DWR or GWT uses) are always a good bet, they have been around for a long time and will live on long into the future. UI on the server only makes sense when the output device is dumb (a teletype, a green screen terminal, or some older phones), and yes I have written my share of green screen applications and not longing for the return of that paradigm...

Tony BenBrahim


Jeff Liu replied on Tue, 2008/06/17 - 9:52pm in response to: Tony BenBrahim

Hi Tony Brahim

You might want to give ZK a try and then make the judgement

Tony BenBrahim replied on Wed, 2008/06/18 - 5:42pm in response to: Jeff Liu

I have a development backlog going well into 2009, and there are over 60 Java web based frameworks, with more coming out all of the time, so I surely do not have time to try everything new that comes out, I have real work to do.

There has got to be compelling reason to even try something, and sorry, I do not see it. I am tired of markup, custom tags, custom scripting inside tags,  expression language, if I wanted to do that, I would use JSP, JSF, Seam well before I looked at ZK.

Sorry, but I see very little new here. Custom tags that generate client side code, wait I saw that before in tag libraries ...Rather than bashing GWT and other librarie, the author could have spent more time clearly explaining why this is different and even better than JSP (with tag libraries) or JSF, or Seam.

I can make my own decision if this is suitable for enterprise development and better than GWT (if even comparable to GWT) given enough info about ZK and its philosophy. Unfortunately that is lacking in this article, and I am as likely to investigate ZK as I am to investigate Apache Wicket after reading this article (which is near 0 chance for either).

 Tony BenBrahim




Jeff Liu replied on Thu, 2008/06/19 - 10:10pm in response to: Tony BenBrahim

Hello Tony


An comparing article between JSF and ZK will be released soon to explain the difference between JSF and ZK

Thank you for your comment 

varan kumr replied on Sun, 2008/10/05 - 6:48pm

There is a lot of fud here by people who do not seem to have done serious development in either.


My take:


A ZK application  is much simpler to develop, not just in terms of lines of code, but also in terms of the ease of  comprehension of the conceptual underpinnings of the frameowrk.  In GWT you have to worry about the demarcation between the server side code and the client side code, and have to explicitly make remote calls in the client side.


On the other hand you can write a ZK application just like a Swing application. Make your GUI component, write event handlers and your are done. If you use a ZK richlet you can do it all in Java without a single line of HTML or XML (ok sometimes it's easier to use the ZK Html component but that may be a small part of it). But you never have to worry about what code is running where.


I have the sense that GWT may be faster and more scalable, but looking at the API of both I decided to use ZK for an application whose earlier incarnation sufferred from incredible sluggishness, and the experience has been overwhelmingly fulfilling, and ZK has come out with flying colors.

Kenneth Mark replied on Sun, 2008/10/05 - 7:05pm

Thanks for the comparison. I'm in the middle of evaluating Ajax framework for my company and yours articles helps a lot. 

varan kumr replied on Sun, 2008/10/05 - 7:27pm

I would like to make one more point here.


 The quality, or lack theroef, of its documentation nowithstandinng, the ZK frameowrk is a conceptual breakthrough for development of web applications. Conceptually, GWT is not too diferent from the old style of web frameworks: you develop the server side code, the client side code, and connect the two, just as one did in the prehistoric days of the web. Any programmer worth his salt will quickly recognize that a ZK application can be developed without paying too much attention to these boundaries.

 I am so impressed by ZK that I would venture to predict that even if ZK does not succeed, sooner or later a major palyer like Google or Yahoo will come up with a framework similar to ZK because of the simplicity of the ZK approach. Such a development would of course be driven nort only by some of the specific drawbacks of ZK but more importantly by the essential superiority of ZK over the other web frameworks.


In case I appear to be too ardent a fan of ZK, I must point out that I have no connection whatsoever with the developers or their company. 

kent tong replied on Sun, 2008/10/05 - 8:20pm

Serious faults with this article:

1) The content ("ZK is easier than GWT") doesn't support the conclusion ("right tool for the right job").

2) The comparison ignores the design objective of GWT which is UI interactivity and thus flavors ZK unfairly.

Joonas Lehtinen replied on Mon, 2008/10/06 - 1:14am

In my (biased) opinion, doing all the UI programming in Java-language has a huge benefit over markups: it promotes OO design and makes refactoring and code maintenance much easier. This out-weights the benefit of faster prototyping of declarative UI building with markup-language. Also additional plus is that programmers doesn't have to learn yet another XML-dialect and are forced to use IDE that happens to have editor (with syntax-helpers) for that particular markup-language.

On the other hand: doing everything on server-side makes life easier: no more cross-browser worries, direct calls to any server-side API:s, no explicit communication layer design, no double-validations and in many cases - more secure application.

Currently the only framework that builds on this server-side RIA in Java ideology and also leverages GWT to allow widgetset extensions in Java is IT Mill Toolkit. (Apache-license) 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.