ZK vs. GWT : Server-Centric Matters!
[ Jeff Liu is an engineer with Potix Corporation, who are creators of the ZK framework ]
Contents
- Abstract
-
Server-Centric and Client-Centric
- Where Applications Run
- Server and Client Centric Ajax Frameworks in Practice: ZK and GWT
- 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)
-
ZK vs. GWT in Action 2 : Data-binding
- ZK (1 File, 39 Lines of Code)
- GWT (4 Files, 200 Lines of code)
-
ZK vs. GWT in Action 3 : Live data
- ZK (1 File, 15 Lines of Code)
- GWT (I Don Even Want to Code It)
-
ZK Anywhere
- What about the devices without browsers?
- ZK on Java Phones
- ZK on Google Android
-
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.
so security compromises that exploit client-side state and logic are more difficult to pull off.
The developers can work in one language (on the server) and, for the most part,
ignore the fact they are writing a web application.?/cite>
- by Dietrich Kappe, Chief Technology Officer of Pathfinder
To Know more how ZK works as a server-centric framework, refer to the following:
- Login or register to post comments
- 9687 reads
- Email this Article
- Printer-friendly version
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
aburo replied on Mon, 2008/06/09 - 11:28pm
Thanks for the post. It's helpful.
After internal evaluation, we decided to go with ZK. The easiness is the beauty of ZK!
robbiecheng replied on Tue, 2008/06/10 - 1:02am
windperson replied on Tue, 2008/06/10 - 3:00am
chicwalk replied on Tue, 2008/06/10 - 3:59am
Fred Barney replied on Tue, 2008/06/10 - 9:23am
Mark Haniford replied on Tue, 2008/06/10 - 9:32am
in response to: fb43282
pohl replied on Tue, 2008/06/10 - 10:19am
This article is for the extremely-gullible. It is based upon the false premise that using GWT somehow prevents you from placing logic on the server-side wherever you deem it to be appropriate.
Why bother to read on after that?
Dino replied on Tue, 2008/06/10 - 10:53am
in response to: pohl
The article is not very convincing. Lack of knowlegde and technique is evident when describing GWT.
Ray Cromwell replied on Tue, 2008/06/10 - 1:33pm
This comparison is a failure on so many levels:
1) The whole raison d'etre of GWT is maximizing performance and minimizing network i/o. Studies have long shown that every few hundred milliseconds of delay loses users. ZK adds more network roundtrips, consumes more bandwidth, and adds more headache for scaling up the server.
2) GWT *aggressively* optimizes Java to JS. The compiler is the centerpiece. It is not just about translating Java to Javascript, but optimizing JS. Does ZK even come close?
3) GWT Deferred Binding mechanism allows automated packaging of resources into single HTTP request. ImageBundle for example, automatically turns your image resources into "css sprites", collapsing N HTTP requests to 1.
4) Managing all presentation state on the server is less scalable.
5) Relying on the server to update the client view generates needless network traffic.
6) GWT is not "all or none". You can do as little or as much server-side processing as you want. To give you an example, I'll cite Lombardi Blueprint, a diagramming tool written in GWT. It runs diagram layout algorithms in the client first, and if they turn out to be too slow (per machine, browser, or diagram complexity), it transparently runs the same Java class on the server. GWT very much enables mobile code to move from browser to the cloud. I'll also cite my own GWT charting library Chronoscope, which can generate charts inside the browser, or delegate the same server.
7) GWT can do declarative UI if you wish (see Declarative UI in gwt incubator). The difference again is, the UI templates are *compiled* yielding much smaller code and higher performance at runtime.
ZK looks like a Web 1.0 framework with 2.0 features tacked on, that doesn't give you anything that you couldn't get already with Wicket, Echo, Click, etc. Fine for some problems, but I wouldn't dare build something like Google Spreadsheets with it, or 280slides. The Android example shown totally fails in offline situations where a native app, or GWT + Gears wouldn't.
Instead of comparing with GWT, you should be comparing with Wicket/Tapestry/Click/Echo/RIFE or even Jaxer.
Jess Holle replied on Tue, 2008/06/10 - 1:38pm
One must always assume someone can use whatever remote API your server exposes in whatever perverse way they want and guard against that.
That said, a web services API supporting many different clients and having no client-specific logic in it would seem to have many advantages. Burdening the server with client logic and state reduces server scalability and increases server complexity. It's a great idea if you're selling server hardware or high-falluting, expensive app servers or the like -- and not necessarily a good idea for anyone else -- except, of course, where you have to support brain-dead clients, which is not the GWT market niche anyway.
jebberwocky replied on Tue, 2008/06/10 - 9:01pm
in response to: rc97555
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 :)
jebberwocky replied on Tue, 2008/06/10 - 9:06pm
in response to: hucmuc
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.
hksduhksdu replied on Wed, 2008/06/11 - 10:03am
Thanks for the great article! Good work!
But I think AJAX's use is to minimize the roundtrip between client and server. To accomplish the best result, I would choose a "Data Centric" strategy. Client computers are good enough to perform processing on client side these days and all it lacks of is resulting data. In my view, I see middleware as CPU and Memory (cache) where EIS layer is the hard drive. Client browser, in this case, becomes video card and monitor. To render information on client browser, we not only require data but also the layout of presenting it. Client browsers will then extract, transform and load the presentation layout data and the actual data. For data manipulations, "rendering program" should be able to selectively send the required data to the server for calculations and send it back and refresh the calculated data.
e.g.
1. Presentation Layout Data - XML/XSLT
2. Data - XML
alexmoffat 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.
jebberwocky replied on Mon, 2008/06/16 - 5:25am
in response to: alexmoffat
Hello Alex
Thank you for the comment.
From my personal experience, ease of developlment is critical for large enterprise application development.
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 ongwt.com)
"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
jebberwocky replied on Tue, 2008/06/17 - 9:52pm
in response to: tbenbrah
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: jebberwocky
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
jebberwocky replied on Thu, 2008/06/19 - 10:10pm
in response to: tbenbrah
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
Anilkumar GT replied on Fri, 2008/07/04 - 1:16am
Tony,
With all due respect .... in the amount of time you have spent writing up your thoughts aboutZK ... you could have easily written couple of screens with ZK that would have showed you how easy it is use and how elagent it is ....
just because you have not heard about ZK (or too many folks have not heard about it for that matter) and do not know the authors, it does not make ZK a bad framework ....
After having used ZK on my "pet projects".... i think it is a fentastic framework ... and every time a AJAX survey is done, the first thing i look for "where is ZK"... and i am disappointed that it is not getting its due ... which could be for various reasons like: .... say the name itself, maybe their dual licensing etc...etc...
but having implemented my pet projects in both GWT and ZK .... given the ease of use, intutiveness and more importantly simplicity .... ZK is my clear choice.... so give it one hour and then make up your mind...
cheers,
GT