An Interview with ZK Creator Tom Yeh

Anyone who has been following the development of AJAX frameworks has heard of ZK, the server-side component GUI framework that allows you to write applications like you would a desktop app. It has become one of the most popular projects on sourceforge and has been nominated for a 2006 Community Choice Award.

Recently I talked with one of ZK's creators, Tom Yeh of Potix, about the Framework's popularity and future.

ZK Background

DK: How did you come up with the idea for ZK, i.e. an AJAX framework that allows you to write webapps like you would a desktop app?

TY: As I mentioned in, it is the result of frustration.

I was a fan of thin-client computing since leading a wonderful team to develop Network Computer and Window Terminal in 1995. I truly believe in the so-called utility computing. Accessing applications should be as simple as using tap water.

It is crazy that someone should carry tons of water when traveling, since tap water is available everywhere. However, we still travel with notebooks, even though Internet connectivity is everywhere. Similarly, the Web edition of MS Outlook has been available for years, but we are still using the desktop version. Why? Frustrated user experiences and excessive development costs. In other words, it is too costly to develop a Web UI from scratch or add-on to 'legacy' apps, and people won't use the Web UI even if it is provided.

After trying different ways to apply Ajax in the projects on which we consulted, we found that applying Ajax at the client side, as most frameworks did, only solved the half of the problem -- though it did result in a lovely interface. That is why ZK was born.

DK: Who is Potix?

TY: Potix is a consulting firm providing expertise in Web development and project management. We also develop applications on an ODM-basis. ZK is the consequence of this work. However, due to strong demand, we mainly focus on ZK now.

Potix is also a house of old dogs. Most of us have more than 15 year of experience, ranging from developing Windows/Linux/Web applications, to embedded OS and GUI frameworks. ZK is my second OSS project; the first one, called OpenPam (GUI for embedded devices), was not very popular.

DK: How are you planning on making money with ZK? Nextapp, the makers of Echo2, sells an Eclipse plugin for around $400. Is that a business model you are examining?

TY: Dual license (as MySQL did). You might also take a look at one of my posts:

Other Frameworks

DK: Echo2 seems to be the only other server-side AJAX framework out there. How would you compare yourself with Echo2?

TY: Echo2 assumes UI designers are Swing programmers, while ZK assumes many of them are not programmers.

Markup languages, like HTML, XUL and XAML, scripting languages, like PHP and Ruby, and the object oriented approach are the three most important developments since GUI was introduced. Unfortunately, Echo2, WebOnSwing and similar frameworks only focus on the object-oriented approach.

In addition to BeanShell, we are looking at the possibility of using Ruby and PHP in zscript. It looks to be, so far, quite feasible.

DK: There's lots of talk now about the Google Web Toolkit. Do you see it as a competitor to ZK or a complement?

TY: Both.

From a technological viewpoint, it is a complement. GWT is a client-side solution and quite good for developing Ajax components. On the other hand, it is never a good idea to replicate the business logic to the client, which eventually brings us back to the maintenance headache of fat clients. In addition, loading huge JavaScript files into the client and executing them there is not fun at all. At the end, you need a server-side solution to handle the business logic and presentation tier.

It would be great if we can leverage GWT's power to simplify the effort of component development (as we did with DOJO and FCKeditor).

From a perception level, users might see it as a competitor. Google is now at a sweet spot with plenty of resources and a good reputation, as Microsoft was in the 1980s. Developers love to explore any kit Google puts out there and exaggerate what it can do as if Google was the first to invent it.

DK: Do you envision developers writing ZK components using GWT?

TY: Sure, GWT does a good job for non-JavaScript programmers who want to develop Ajax components. I expect that some results of this will show up in next few months.

However, what makes Ajax programming difficult is not JavaScript itself. Rather, it is the incompatible and buggy API (to communicate with DOM). The ability to do Java-to-JavaScript is important, but I am also hoping for some benefits from the standards efforts of OpenAjax.

The true value of ZK is its architecture. We look forward to adapting components to ZK as decent (client-side) Ajax components become available.

DK: What other AJAX tools, frameworks or technologies do you think are noteworthy or interesting?

TY: DOJO has an amazing set of components, though it is too heavy (one of the reason we didn't build the ZK Client Engine upon it). Atlas has great integration with Visual Studio. Anyone who wants to provide an authoring tool should take it as an example. Google Spreadsheets is an excellent Ajax application. You should unplug the network connection and see how it reacts, though. It's cool nonetheless.

Strengths and Weaknesses

DK: What would you say are the strengths and weaknesses of the ZK framework?

TY: Strengths: boundless. But seriously, great richness and excellent productivity, if we can put in a sentence.

Many of ZK users appreciate that they can design a rich Web application without programming. Many have thanked us for the intuitive event model and feature rich components that have saved them countless hours. Many enjoy the power of prototyping so they can change the look and function right in front of their customers. For more information, you could take a look at the executive summary (


  1. Stops working if the connection is broken. It would be better if a subset of functions still worked (such as read only viewing).
  2. Round-trip latency, though hardly observable. To minimize the effect of this, we plan to, in addition to Client Side Action, add visual effects that execute solely at the client and notify the server only when necessary.

One other weakness shared by all HTTP-based solutions is the lack of Server-side push. Though someone has implemented so-called "reverse Ajax", it introduces too much overhead on the server. This -- server-side push -- is the next important step beyond Ajax.

DK: There aren't any production applications out there using ZK. Do you see that as a problem and, if so, what are you doing to address it?

TY: According to the profile of our customers, adopting ZK is still in the development (and evaluation) phase. By and large, adopting
Ajax for most companies is still in an early stage. It is just a matter of time. I'm not really that concerned about it as long as the growth of ZK's acceptance is strong.

DK: Right now, the framework doesn't seem to allow for easy customization of the look and feel (window color, font, etc.). First, is that correct and, if so, do you have any plans to address it?

TY: Not correct. The look and feel are well separated by CSS and molds. What prevents users from customizing the look is the lack of documentation and samples. Also, the customization of the sophisticated components is sometimes not intuitive. It forces users to look at DSP files (the templates used to generate HTML tags). We realize this is an issue and we will provide documentation in the Developer Reference guide.

DK: I've noticed in the code that you spawn another thread to handle events. Can you explain the design to me? Also, how does this fit in with the Servlet standard and doesn't this make it difficult to cluster a ZK application if the user session has non-serializable information and context?

TY: It is common that an application has to confirm with users about, say, whether to delete a file. It is unbelievably costly for Web developers to implement such functions. Why? Users get no response until the servlet has completed, while the servlet requires user's confirmation to decide whether to proceed further.

There are many solutions to this problem, but the most elegant one is modal dialogs. ZK is one of the first Web framework that really enables the server-side modal dialog. The magic is to process events in another thread. Then, users can suspend and resume the processing anytime they like -- including but not limited to modal dialogs.

It does make clustering difficult if there is a pending thread in a session. We are working on the serialization issue now. A basic idea is to send the application a notification, and it can decide how to handle pending threads. Of course, if there is no pending thread, there is no notification at all.

DK: What is your favorite ZK feature?

TY: Macro components, the threading models, and zscript.

DK: Are there some cases where you wouldn't use ZK to develop an AJAX-based web application?

TY: Hard to imagine unless clients want the application to be functional even if the connection is off. Oh, action games, but it might not be a good idea to use Ajax there at all.

DK: It doesn't appear that you are using JUnit in the ZK code. Is this true? And if so, why?

TY: Only common utilities are tested with JUnit (refer to pxcommonTest in SVN). I am still thinking about which is the best way to test ZK components. We will come out with something in the near future.

Future Plans

DK: What is the biggest feature enhancement request you are getting from the users of ZK?

TY: Safari support and design patterns. By design patterns I mean information on how to really write an application with ZK. An illustration with Pet Store is a common request.

DK: On your road map you mention plans to provide a mobile version of ZK. First, what is the time frame for this? Second, how are you planning to do this architecturally? Can users write one application and dynamically re-target their apps to a different front end?

TY: We originally planned to provide a J2ME-based client engine, but we are keen on developing a Flash-based solution now. Architecturally, we have to do three things to support a new client: client engine, server engine and components. Users have to do two things accordingly: use a different set of components and adjust their UI to fit into small screen. We will keep the component API very similar (and also provide common interfaces that make developer's code polymorphic).

It is possible to let users use the same set of components, where components would be smart enough to detect the client and behave differently. However, we're not considering this approach because it makes the development and maintenance of components too complicated. Of course, we can use the factory pattern to chose the correct implementation, but it makes the instantiation of a component too complex for most users.

DK: You've stated that ZK is at the interface layer. Do you plan to introduce components that punch through to the data layer, sort of like the .NET datagrid?

TY: Yes. We will add more data-layer utilities, such as zkplus's DelegatingVariableResolver, too. After all, most ZK applications will have to access a database. However, we may not do a similar deep integration as Ruby on Rails did -- I don't like to make so many assumptions about how applications might be built.

DK: What do you see as the major challenges facing the AJAX community today?

TY: There are too many frameworks, such that many users prefer to wait. There isn't even a well-recognized categorization for them (such as server vs. client). A comparison chart or something similar would be very useful.

A standard like OpenAjax will help (at the client side), but I've never seen an alliance really work.

DK: Care to share any other plans you have for ZK?

TY: We are interested in adding mega-components, such as spreadsheet, forum and wiki. Part of the success of PHP is because the availability of plenty of off-of-shelf stuff. We won't develop all of these components ourselves. Rather, we prefer to help other developers deliver them either as OSS or commercial components. We will have a ZK.forge website to promote such collaborations.