Re: wicket vs vaadin clarifications

Hi all,

If there are any errors in our comparison table, please accept my apologies -
I wrote the original version of the table. I take care that any errors will be
corrected as soon as possible. Just to clarify the situation - I think that
wicket is a nice framework and really want to give it a fair comparison.
In my opinion, Vaadin is better for some applications and Wicket for some.

Here are quick comments to your concerns.

francisco treacy-2 wrote:

Widget diversity & richness:
- (I guess richness means Ajax-enabled components?). You put 1 star -
but there are plenty of 3rd party Ajax components for Wicket... for
instance have a look at wicketstuff.org.

I did this comparison purely by looking at the available demos and comparing available ajax-enabled components on http://wicketstuff.org/wicket13/compref/ that I thought to represent the wicket core component set. You can browse through the core widgets (with code examples) on
http://demo.vaadin.com/sampler/

Unfortunately I did not include wicketstuff - is there a (online or offline) demo available? On the other hand - I also left out all the extra Vaadin components on http://dev.vaadin.com/svn/incubator/ and from http://dev.vaadin.com/svn/contrib/

francisco treacy-2 wrote:

And by the way, "require you
to use their AJAX API to implement AJAX functionality" is simply not
true. I have created components with jQuery or Mootools where you just
drop the jar in your classpath and don't code a single line of
JavaScript. Further, you reuse the goodness of inheritance to
structure the JavaScript contributions, like <script src="..."/>

Please explain - I thought that in order to make a wicket page "ajax enabled", you should create special Ajax callbacks and use Ajax exabled components as explained in http://wicket.apache.org/exampleajaxcounter.html

In Vaadin all components and rendering is purely Ajax enabled. The above mentioned example re-written in Vaadin would look like:

 package com.example.counter;

import com.vaadin.Application;
import com.vaadin.ui.*;
import com.vaadin.ui.Button.ClickEvent;

public class CounterApplication extends Application {
       
        private int counter = 0;
       
        public void init() {
                Window mainWindow = new Window("Counter Application");
                setMainWindow(mainWindow);
                final Label label = new Label("Not clicked yet");
                mainWindow.addComponent(label);
                mainWindow.addComponent(new Button("Click me", new Button.ClickListener() {
                        public void buttonClick(ClickEvent event) {
                                label.setValue("Clicked " + (++counter) + " of times.");
                        }
                }));
        }
}

Even though the difference in complexity is not that big in example, in large applications it really makes a difference.

francisco treacy-2 wrote:

Framework extensions are done in Java:
- You should tick it - extensions *are* done in Java

By framework extensions here I mean new components/widgets and as the comparison is only about RIA, I mean Ajax enabled components. In Vaadin new widgets are written in Java - both on server-side and on client-side. Client side is compiled with Google Web Toolkit to JavaScript. To read more, see: http://vaadin.com/book/-/page/gwt.html

In order to create a new Ajax enabled widget for Wicket, you must write client-side with JavaScript and server-side in Java - or am I wrong here?

francisco treacy-2 wrote:

No HTML required:
- It depends. There are components that don't have associated markup.

All examples on http://wicket.apache.org/ include some HTML. In Vaadin there is no "page" concept at all. For example, the above "counter" is self-contained - you do not need any html or xml to run it. (ok, you must configure vaadin servlet in web.xml)

francisco treacy-2 wrote:

No XML configuration required:
- You should tick it - no XML configuration is required whatsoever. Of
course, web.xml but... you know.

Ooops. This is my mistake. Sorry. Will be corrected asap.

francisco treacy-2 wrote:

Web-page oriented / Framework tuned for building web-pages/sites
instead of application user interfaces:
- Well, definitions here are quite blurred. But I'd say the sweet
point of Wicket is building highly-stateful application UIs.

You are right - border is really blurred. To draw a line, we should consider what is the "normal" operating mode for the framework. Most Wicket applications require page changes and most Vaadin applications operate within a single page.

francisco treacy-2 wrote:

Commercial support & guarantees available:
- There are various companies that provide support for Wicket

Can you really buy guarantee for Wicket? Any references?

Best regards,
Joonas