Important Notice - Forums is archived

To simplify things and help our users to be more productive, we have archived the current forum and focus our efforts on helping developers on Stack Overflow. You can post new questions on Stack Overflow or join our Discord channel.

Product icon

Vaadin lets you build secure, UX-first PWAs entirely in Java.
Free ebook & tutorial.

Comparison: ZK vs Vaadin

Joonas Lehtinen
1 decade ago Mar 25, 2010 4:38pm

There is an excellent blog post about Vaadin in http://www.dzone.com/links/for_the_love_of_vaadin_java_rias_done_right.html.

The linked blog post has discussions that compare Vaadin to ZK (and others). I'll cut-n-paste some of the Vaadin-ZK comparisons here:

Quick comparison:

  • Vaadin uses GWT for the rendering, ZK uses proprietary client-side. This makes it a lot easier to add more widgets to Vaadin – it can be done in pure Java and there are a lots of good books about Google Web Toolkit that help.
  • ZK embraces XML for user interface declarations. Although you can use pure Java in both frameworks to define user interfaces, Vaadin is designed from scratch to be programmed in 100% Java.
  • Vaadin community is much more active in contributing add-ons to the framework. Today these add-ons are scattered around forums and svn, but starting from Mar 30. Vaadin.com has a good directory where you can just drag and drop new widgets, datasources and other add-ons to your project. In launch there will be about 100 add-ons next week to choose from.
  • Vaadin is released under Apache 2.0 license. ZK has two versions – limited community edition under LGPL 3.0 and full version released under commercial license.


  • ”Vaadin uses GWT but it has different lifecycle. For example, you can’t use GWT builtin components directly.”. True – you must implement one additional method to widget to use it in Vaadin (updateFromUIDL()). Still – IMO – this is a lot better than having to write JavaScript in order to extend the framework.
  • “Vaadin requires to load all JS code no matter a component is used or not.” Not true. You can select to only include widgets you use on the client-side. In practice including all Vaadin standard widgets required 159kb of HTML+JS to be loaded. This is all needed to run Vaadin Sampler demo for example. Starting up ZK Explorer demo loads 158kb of HTML+JS initially when demo is started. While using demo, total amount of HTML+JS grows to 346kb (this does not include any third party integrations like Google Maps or Simile). From this I would say that Vaadin is considerably leaner on client-side.
  • “I were surprised Vaadin does not support Drag&Drop which shall be ready many years ago.” – Vaadin 6.3 includes comprehensive Drag and Drop support. This includes component to component drags, reordering of components, client and server-side drag handlers, HTML5 support for dragging resources from the Desktop. You can use 6.3 today (just download a nightly build) and 6.3.0 RC will be released this week.
  • “ZK has very strong integration with Java technology, from Spring, JPA, MVC… and up to the recent CDI. I don’t see much support in Vaadin”. You should look harder. There are several application stack examples on Spring integration, several JPA integrations, OSGi integrations, etc. Just type your choice of integration to the search field on vaadin.com
  • “ZK has very powerful components, such as calendar and spreadsheet, that cannot be found in Vaadin (including their roadmap)”. Full featured Vaadin Calendar will be released in couple of weeks, but here is no spreadsheet component for Vaadin. On the other hand there are lots of components for vaadin not available for ZK – for example a proper lazy loading timeline component: http://demo.vaadin.com/timeline
  • “Vaadin’s Ajax update is too coarse grained — it tends to invalidate the whole widget if what we need is to change an attribute.” Not true – this is decided on widget by widget basis. In most widgets only the changed attribute is updated.
  • “The strongest point of Vaadin is everything in Java. But, while GWT is a client-side solution, developers, ironically, can’t access the client directly with Vaadin. Every request has to go back the server.”. The idea here is to do everything in Java on the server-side. Client-side only comes to picture when you want to extend the framework by adding new widgets. Then being able to use Java on the client-side is a really strong point.
Ondrej Medek
1 decade ago Mar 30, 2010 1:50pm

Hi Joonas,

I develop with ZK, do not know Vaadin. I have just a few comments:

  • Vaadin design (CSS) is much more prettier then ZK.
  • ZK indeed has lack of community components or addons. One reason is that ZK 5 differs to ZK 3. Other reason is unfortunate license for ZK 5.
  • I like ZK way of defining user interface in XML. It is more readable for non-Java (CSS, HTML) developers. It also nicely enforces developers to separate controller from the view.
  • I think the to use Vaadin or ZK is more about to use GWT or not to use GWT. Otherwise both ZK and Vaading have similar philosophy.
Last updated on Mar, 30th 2010
Joonas Lehtinen
1 decade ago Mar 30, 2010 2:12pm
michele mazzei
1 decade ago Jun 24, 2010 4:05pm
Andrey Fink
1 decade ago Jul 22, 2010 12:45pm
Ondrej Medek
1 decade ago Jul 22, 2010 12:56pm
Andrey Fink
1 decade ago Jul 22, 2010 1:13pm
Andrey Fink
1 decade ago Jul 27, 2010 7:19am
David Kilmer
1 decade ago Aug 02, 2010 2:16pm

Joonas Lehtinen: I am stll doubtful if XML based UI declarations could be a good idea for a framework like ZK or Vaadin.

I'm a ZK user contemplating a move to Vaadin. I'm working on an XML composer for Vaadin, and I thought it might be useful to share my reasons for wanting XML-based layout definitions. A good composer, in my opinion, goes beyond just laying out components. It also auto-wires declared components and event methods.

Here are my reasons for liking XML-based composition.

1. You can make changes to the layout of the container at runtime, which allows you to fiddle with the layout and get it just right without recompiling/redeploying a bunch of times.

2. You can provide several different layouts with the same Java class behind them. This is useful if you want to layout your components differently in, say, a mobile application.

3. It makes the code much cleaner by performing all of the component creation, attribute setting, parenting, etc. in the composer. Your Java class is focused on list models and other logic-type things rather than the mechanics of laying stuff out.

4. Events are more clear in the code when they are wired by the composer. A method called "onClick$okButton" makes it easier for maintenance coders to figure out where the real action happens.

Just some thoughts. In all, I'm starting to think that Vaadin is the stronger product of the two. My only complaint is that the event model is a tiny bit scattered -- it would be nice if all Vaadin events had a common interface.

Doug Ly
1 decade ago Nov 22, 2010 6:08pm
michele mazzei
1 decade ago Jan 12, 2011 4:56pm
Jouni Koivuviita
1 decade ago Jan 13, 2011 7:11am
michele mazzei
1 decade ago Jan 13, 2011 9:46am
Kynao Yooky
1 decade ago Mar 27, 2011 9:07pm
Joonas Lehtinen
1 decade ago Mar 28, 2011 4:27am
Jorg Heymans
1 decade ago Mar 28, 2011 9:30pm

my thoughts on vaadin vs smartgwt :

- vaadin has a 300page high quality manual right there for your developers to start with. This documentation alone will enable your developers to build very solid apps. I did not find the same quality documentation for smartgwt, but maybe it is in their commercial offering that is being referred to so often from their site.
- vaadin is an evolution of 10 years of work and this clearly shows in their API and component model. It has a clean design, responsibility and focus and a very consistent 'no suprises' policy. Keeping a product going and its backing company profitable for such a long time counts towards a lot in my book, it is certainly reassuring and gives a 'these guys really know what they are doing' feeling.
- In smartgwt i get the idea that the api is rushed and just a thin bridge over the underlying javascript library with little added framework value. It just allows you to do whatever the js lib can do, coated with some java syntactic sugar. Also you never really get away from the js/html side (methods like getInnerHtml(), getDOM(), getJsObj) which opens the door for all sorts of black magic hackery that becomes unmaintainable over time. I want my framework to be a framework and add a useful and just-enough flexible abstraction, Vaadin does that.
- Vaadin could do with more widgets. They should just hire a widget developer for a year and bring the framework more or less in line with nowadays 'rich and fancy widget' market, so that this becomes less of an argument in comparisons because it is the first thing users complain about. Not that many people will actually end up using any of those fancy spreadsheet widgets though (for this they will just use excel ;)

just my 0.05€,
Jorg (30 days Vaadin user)

Kynao Yooky
1 decade ago Mar 28, 2011 11:38pm
Henri Muurimaa
1 decade ago Mar 29, 2011 10:58am
Jorg Heymans
1 decade ago Mar 29, 2011 9:26pm
Amit Ramaswamy
1 decade ago Mar 30, 2011 3:33am

Henri Muurimaa: Also, if you are a Vaadin Pro Account subscriber you can vote for the ticket :)

Hmmm... that's interesting. We need to pay Vaadin to have the right to vote.

On the other hand, how can we make sure our request will be implemented? Do we need to pay more?


Take top rank 1 (Ticket#6283) request as an example.
It was opened 3 months ago but still not closed yet even though it's voted as Top 1 priority.

Henri Muurimaa
1 decade ago Mar 30, 2011 6:37am
Sunil Sharma
1 decade ago Mar 30, 2011 9:37am
Henri Muurimaa
1 decade ago Mar 30, 2011 1:16pm
Kynao Yooky
1 decade ago Apr 01, 2011 2:40am
Henri Muurimaa
1 decade ago Apr 01, 2011 7:13am
Artur Signell
1 decade ago Apr 01, 2011 9:18am
Sunil Sharma
1 decade ago Apr 01, 2011 9:48am
Joonas Lehtinen
1 decade ago Apr 01, 2011 11:49am
Oliver Watkins
1 decade ago Apr 01, 2011 2:08pm
Ondrej Medek
1 decade ago Apr 01, 2011 2:21pm
Joonas Lehtinen
1 decade ago Apr 01, 2011 3:19pm
Kynao Yooky
1 decade ago Apr 01, 2011 5:38pm
Kynao Yooky
1 decade ago Apr 01, 2011 9:03pm
Henri Muurimaa
1 decade ago Apr 02, 2011 11:45am
Ondrej Medek
1 decade ago Apr 05, 2011 6:27am
Joonas Lehtinen
1 decade ago Apr 05, 2011 6:39am
Benjamin Seyinbour
1 decade ago Apr 25, 2011 5:56pm
Ondrej Medek
1 decade ago Apr 25, 2011 7:57pm
Benjamin Seyinbour
1 decade ago Apr 26, 2011 12:17pm

...you probably think all the idea behind web application is wrong.

As a matter of fact, I do and as you might have noticed, desktop is the direction web application is heading – with Flex and the (new) JavaFX leading the way.

In our business, it is the user that comes first. You can say that on the one hand, we spoil the user by providing them with the desktop experience and on the other hand we force upon them the primitive web pages created with legacy languages like XHTML, CSS and Javascript that are kept being recycled and repurposed. So there you have it.

rohit prajapati
1 decade ago May 31, 2011 11:42am