Comparison: ZK vs Vaadin

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:

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.

Thanks for the comments!

I am stll doubtful if XML based UI declarations could be a good idea for a framework like ZK or Vaadin. I even released an
experimental XML-based declarative UI support
for Vaadin while thinking about this. Still unsure if this idea is a good or not. But this is clearly a matter of opinion.

So at the moment - if XML based declarative UI is important, one should take a look of ZK. If extensibility is important and you are allergic to JavaScript, Vaadin is the way to go. In any case - both frameworks share the same Server-side RIA philosophy.

I’ve used ZK for our internal web projects and we found it very useful.
Now I’m new to Vaadin, I will use it to compare with ZK, JSF and GWT in general.
I think Vaadin uses a better license strategy than ZK (which extensions are free and which not? which components are free and which not?) and in fact it has a huge number of plugin.

IMHO an xml file, that describes the UI, could be better than plain Java code: because XML syntax is the best choice
for describing “objects”, while the Java language is better for implementing algorithms.

Last but not least: the demo is very beautiful!Congratulations!

  1. About xml configuration:

Please! Add better Spring support, and you will have xml configuration for free :wink:
And also auto-configuration with annotations.

“better” means: no getBean calls, no aspect-j class modification
Example of good integration: http://click.apache.org/
http://click.apache.org/docs/extras-api/org/apache/click/extras/spring/SpringClickServlet.html
it is seamless, you just write your Page classes and DI/IoC just works, out-of-box.

Also for example look at this:

http://community.livejournal.com/ru_java/460539.html#comments

A Swing application declared in Spring xml, nothing special, only core old Spring.

  1. log4j / slf4j / logback author thinks that “configuration files written in Groovy which are more convenient than configuration files written in XML”.

I dislike Groovy, but main idea here is: use DSL for your domain.

So may be alternative configuration in DSL written in Clojure will be good addition to Vaadin.

Andy, we are talking about XML based UI, not XML configuration in this thread. And we are comparing RIA frameworks, and do not discuss integration with Spring.

Wow. 3 contrary assertion in one post :wink:

I think this forum thread about “Comparison: ZK vs Vaadin”.

we are talking about XML based UI, not XML configuration in this thread.
If you can make your UI in xml, do really worry “what exact type this xml is”?
I think well-known xml are far better.

“integration with Spring” is big plus (I think “must have”) for RIA framework (if you compare them, remember?)
It has higher priority than “XML based UI”.

The main problem with ZK: its next-one language to learn.

With “standard” spring xml you will kill 2 hares:

When somebody see this http://www.zkoss.org/product/zkspring.dsp
he thinks “ZK is better”

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.

You may want to look at this post here.
http://vaadin.com/forum/-/message_boards/message/234396

I’m still developing the XML based UI for Vaadin. It looks pretty promising (for me :-))

Cheers

I used Zk and I enjoyed very much.

I used Zk for a small (internal) project and I found it very productive.

Then I tried Vaadin for a joke, and I was very impressed!

IMHO today Zk and Vaadin are the two best Java Web Frameworks.

I think that in future I will invest on Vaadin because of its open license.

I would like to ask a question:

I noticed that the Zk’s table component is very powerful because you can put any complicated panel inevery table-cell (i.e. you can put in every cell anything you want),
on the other side with Vaadin I noticed that this is not possible.

Is it correct?

Do you have planned to improve the grid component (and the tree component too) ?

Bye.
Michele

You can place other components inside table cells. Just set the column type to a component class. In theory you could even put a table inside another table, but I don’t recommend it :slight_smile:

Thank you.
It’s correct according to the manual:


components table

Bye
Mike

I never gave Vaadin a try but looking at it for a long time and it’s pleasant to see talented people keeping the good work on the road, congratulations for its improvements over time. I’m also glad to see that Vaadin is, little by little, closing the gap with ZK. Push is finally coming which is good news.

Well, first, it has to be proved, second, it’s a lot easier when the widgets are available :grin:. Advanced widgets are available into ZK, i didn’t really see them into Vaadin. Maybe i didn’t look the same showcases as the people saying that :bashful:
Third, i like the GWT approach but in practise, if i want my user not coming back, it’s a good idea to use GWT widgets as they’re everything except appealing… until someone deliver a good quality gwt widget kit. Anyway, can we use GWT designer in any way with Vaadin ?

Ok but where are the advantages ? For example, David Kilmer exposed here valuable reasons why XML-based composition has also its advantages.

So why ZK has more numerous sophisticated widgets ? In terms of widgets and as i see, ZK is nearly comparable with ext GWT and smartGWT. Vaadin is not (yet i hope) in the same “world”. By the way, i didn’t see mobile target in vaadin as we have it in extjs, ZK and SmartGWT [i’m not sure to well understand by apparently Vaadin 6.6 would begin the mobile support, to verify as it seems the need of the pro account]

Ah, i have to give a better look into this, that would be excellent news to see the valuable components we see into ZK, i’m dying to see them :slight_smile: as i’m currently searching reasons to dive into Vaadin instead of ZK; and widgets are among the things difficult to ignore :slight_smile: except when killing features are available in one product and not in the other. For example, if Vaadin applications could work on a cluster automatically and without additional work, that is the zero-state scalability like we have into SmartGWT and soon in Wicket, then i would care less of widgets and would be ready to completly forget ZK :love: . By the way, will we see a visual builder like ZK studio ? (Apparently a visual designer is mentionned in the roadmap)

Yes, nothing to say here, that’s a clear very important Vaadin advantage… Except one thing :open_mouth: take into account Vaadin commercial add-on and it seems Vaadin is finally more expensive, i didn’t check for ZK but i’m pretty sure Vaadin would be much more expensive than smartgwt :bored: that left me pensive 8o

Both Vaadin and ZK allow building dynamic web app into one page so some would say that SEO needs would be irrelevant, i would not agree :), not natural yes, but irrelevant, no. By the way, ZK is SEO friendly :P. As GWT is not friendly with SEO needs, i guess Vaadin is not adapted too.

Final note : in fact the thing that would be bun and would calm down the widget debate, is to support LGPL Smart Gwt as an add-on, that is the client side. By the way, that would cover much of the missing points of this comparison table :slight_smile: http://www.smartclient.com/product/competition.jsp and instead of only framework competition, it would be by part framework collaboration :slight_smile: even if on the competion side, Vaadin with such an add-on would become better than ZK or extGWT :smug:.

See the widgets and demos in
http://Vaadin.com/directory

Yes. Just install it from eclipse marketplace or from vaadin directory today.

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 :wink:

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

[quote=Joonas Lehtinen]

Yes, i had already looked every pages of that space :slight_smile: but in the context of the comparison, subject of this thread, i would say that community add-ons are a great added value for a product but are not basically the strengh of the product. That’s why, to my mind, we can’t compare whatever zk, smartgwt versus vaadin + community addons.

In more details : for more than one reason, i’m glad Vaadin has a successful add-on directory around a community contribution, that’s something quite usual in php frameworks but not so usual in java frameworks, so that’s an advantage over smartgwt or even zk for which such a space is not very much formalized and everything is almost in the package.

On the other side, i would not compare community work over what is included into the related product in the first place for many reasons :

  • whatever the product (framework, cms, dms,…), i can’t remember a community place where the contributions status like experimental, alpha, beta… were not in majority over stable contributions. I even don’t talk about certified status :V

  • community add-ons are very unusually backup by a company. Most often, the nice person behind an add-on either stop before the add-on reach an interesting status or finally does not maintain it. :kid:

  • when i mention “maintenance”, i mean maintenance over the releases of the underlying product… Depending of the add-on nature, some addons are not really reasonable to be found in a community directory instead of the product itself. For example, building a cms with the help of Vaadin, i can tell you that i would be far more confident to see ckeditor support into Vaddin itself instead of the community add-on. Another example : when we have no other solution, that’s cool to see an add-on bringing push capabilities but that’s far more cool to see it in the core. There are add-on nature which correspond perfectly to an add-on directory, i don’t see my 2 examples fitting the situation.

I see community add-ons as an added value, not a replacement

13 of those
160+ add-ons in the Directory
are offered and maintained by Vaadin Ltd. They are add-ons mostly because we don’t want to bloat the core.

We’re also very interested in what kind of component our users need and want, so please let us know if you have ideas. The best way to suggest ideas to us is to create a ticket about it
in the Trac
(free registration required). That way the discussion stays in one place, though you could also link a ticket here in the forum for added visibility.

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

How would adding more widgets bloat the core ? Would it take longer to initialize and load a new application in the browser if Vaadin had let’s say 1000 widgets in the core then if it only had 100 ? (even if the application just uses 10 widgets?) … My guess is not and i hope i’m not wrong. Unless you mean that adding new widgets inevitably means adding new features in the core to support the creation and features of those widgets, then yes i can see the core getting bloated.

Jorg

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?


http://vaadin.com/feature-voting

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.