Vaadin vs ZK ?

answered 2013-12-10 18:58:40 +0800

windeyu
288 ● 3

We've worked on the ZK framework for years now. All of our pages are programmatically generated with dynamic contents without specifying fixed with and height on the container UI. We use lots of vflex and hflex to let the ZK framework to lay out for us. It did take some experience to do it well, but it's true for any other software. So far we haven't encountered stoppers in our layout with the ZK framework.

One thing I would like to point out is that Vaadin spent more effort in marketing than ZK. Vaadin had booth in Java One conference every year to showcase their product, and passed out free goodies to attract developers. When I talked to people, Vaadin was well known, while many never heard of the ZK framework. I hope ZK can expand their visibility.

answered 2013-12-09 16:41:14 +0800

cyiannoulis
1201 ● 10

updated 2013-12-09 16:45:19 +0800

Vaadin was one of the candidate frameworks when we were trying to evaluate some of them about 1.5 years ago. It is not a bad framework at all, and we have used it in some small projects just to have fun with it, but now after implementing three ZK based web projects in our company i can point out some things:

1. Vaadin is not GWT. It is a server-side framework (just like ZK) using GWT to create widgets just like ZK uses jQuery. You are not taking advantage directly of GWT features. On the other hand, in ZK, you can take advantage of jQuery and embed a jq plugin quite easily in a ZUL page.

2. If you have developed much code in the past using SWT or Swing you will find vaadin a natural approach. I am one of them. I have written (even with the help of "rightclick -> add event listener" tools) a few thousand event handlers. With ZK MVVM all i do is: button label="Save" onClick="@command('saveRecord')
   and that's it!

3. The wording "vaadin is backed up by google" is much like the same as "zk is backed up by jquery". There is no 100% guarranties for compatibility with future versions of gwt or jquery. If google announce tomorrow the new version of GWT then vaadin (and this is normal i believe) will not be compatible with the new version. The same goes for ZK. Personally i believe it is much more possible in the future for Google to abandon GWT just like Adobe did with Flex. On the other hand a few million developers will always keep supporting jQuery.

4. Vaadin is an intrusive framework. If you have used spring core you know what i mean. Spring's success is primarily due to the fact that the developer all he needs to know is how to declare a new <bean>. No subclassing and no interfaces to implement. Just POJO. The same happens in ZK with the MVVM approach. The "controller" is nothing else but a pojo. On the other hand, in vaadin, you have to learn a whole new API. Of course the same is true if you use the ZK's "richlet" approach which means forget about ZUL and write everything in java. Learning a whole new API means also that a new member in your team has to be familiar with such a development style. There is a great testimonial about Dreamworks saying that a new programmer will take less than a week to start use ZK effectively. Personal experience? It's true!

IMHO if i had to use GWT i would prefer to use GWT directly with the tools provided by google (Eclipse WindowBuilder is a great tool). One of the advantages (and disantvantage also) GWT offers is that the code runs entirely on the client (browser). Because of this, a native GWT application seems to be more responsive compared to an app written with a server-side framework (jfaces, vaadin, zk etc) especially over a slow internet connection. On the other hand trying to maintain a big application written in pure GWT is a nightmare for me.

Something for the ZK team: Vaadin has a great default theme for enterprise applications. It has the right size of buttons, very elegant window titles, the right spacing and pading. Is it so hard to implement a similar theme in ZK? I think that neither Breeze nor Atlantic offer an "enterprise" l&f like vaadin does.

/costas