You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by francisco treacy <fr...@gmail.com> on 2009/07/06 12:21:50 UTC
wicket vs vaadin clarifications
Hi all,
After I tweeted a criticism about http://vaadin.com/comparison table,
some employees/supporters quickly got back to me asking to elaborate
on the problems.
I thought it would be good to make it clear and post it to this
mailing list. Feel free to comment on my points.
Dear Vaadin people:
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. 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="..."/>
Framework extensions are done in Java:
- You should tick it - extensions *are* done in Java
No HTML required:
- It depends. There are components that don't have associated markup.
No XML configuration required:
- You should tick it - no XML configuration is required whatsoever. Of
course, web.xml but... you know.
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.
Commercial support & guarantees available:
- There are various companies that provide support for Wicket
Francisco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket vs vaadin clarifications
Posted by francisco treacy <fr...@gmail.com>.
> Even though the difference in complexity is not that big in example, in
> large applications it really makes a difference.
Yes, the example looks pretty much like Wicket. IMO what will make a
*real* difference is using another language - Java is Java with its
strengths and weaknesses; on the verbosity side there's not much to be
done.
Anyway, thanks for updating your comparison table and I wish you the
best of lucks with your project.
Francisco
2009/7/6 Joonas Lehtinen <jo...@itmill.com>:
>
> 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
> --
> View this message in context: http://www.nabble.com/wicket-vs-vaadin-clarifications-tp24353170p24356576.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket vs vaadin clarifications
Posted by Vladimir K <ko...@gmail.com>.
Joonas Lehtinen wrote:
>
>
> I only included frameworks that I get the most questions about. We
> definitely should include ZK also, but validating some facts would need
> some quick research. If you are familiar with ZK, could you contribute ZK
> column to the comparison table?
>
No, I'm not familiar with ZK enough to contribute a column. Amount of its
ads is quite impressive so I assume it has a certain piece of market pie.
However I refused ZK 'cause it looks not so attractive in technical
internals.
Joonas Lehtinen wrote:
>
>
> Vladimir K wrote:
>>
>> I find Vaadin demos not very responsive. They react very very slowly. At
>> that internet responses are less than 100ms and response size mostly less
>> than 1K and there are only one-two roundtrips for each user action. The
>> same about every GWT application.
>>
>
> That is strange. Did you try the demos on http://demo.vaadin.com/ that is
> hosted in USA (Amazon EC2 EAST) or did you run the demos from local server
> (download vaadin package and run start.sh)?
>
I run online demo. It just came to my mind that this sort of discussion
probably is offtopic.
--
View this message in context: http://www.nabble.com/wicket-vs-vaadin-clarifications-tp24353170p24413008.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket vs vaadin clarifications
Posted by Joonas Lehtinen <jo...@itmill.com>.
Vladimir K wrote:
>
> I'm wondering why your comparison table does not contain ZK?
>
I only included frameworks that I get the most questions about. We
definitely should include ZK also, but validating some facts would need some
quick research. If you are familiar with ZK, could you contribute ZK column
to the comparison table?
Vladimir K wrote:
>
> I find Vaadin demos not very responsive. They react very very slowly. At
> that internet responses are less than 100ms and response size mostly less
> than 1K and there are only one-two roundtrips for each user action. The
> same about every GWT application.
>
That is strange. Did you try the demos on http://demo.vaadin.com/ that is
hosted in USA (Amazon EC2 EAST) or did you run the demos from local server
(download vaadin package and run start.sh)?
- Joonas
--
View this message in context: http://www.nabble.com/wicket-vs-vaadin-clarifications-tp24353170p24412543.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket vs vaadin clarifications
Posted by francisco treacy <fr...@gmail.com>.
Well, still unchanged - I guess we should cut the noise and leave them
put whatever they want in their "comparison chart".
Francisco
2009/7/9 Vladimir K <ko...@gmail.com>:
>
> Joonas,
>
> I'm wondering why your comparison table does not contain ZK?
>
> I find Vaadin demos not very responsive. They react very very slowly. At
> that internet responses are less than 100ms and response size mostly less
> than 1K and there are only one-two roundtrips for each user action. The same
> about every GWT application.
>
> Wicket ajax responses in our application sometimes exceeds 30k and I don't
> notice any lags.
>
>
> Joonas Lehtinen wrote:
>>
>> 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.
>>
>>
>
> --
> View this message in context: http://www.nabble.com/wicket-vs-vaadin-clarifications-tp24353170p24409410.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket vs vaadin clarifications
Posted by Vladimir K <ko...@gmail.com>.
Joonas,
I'm wondering why your comparison table does not contain ZK?
I find Vaadin demos not very responsive. They react very very slowly. At
that internet responses are less than 100ms and response size mostly less
than 1K and there are only one-two roundtrips for each user action. The same
about every GWT application.
Wicket ajax responses in our application sometimes exceeds 30k and I don't
notice any lags.
Joonas Lehtinen wrote:
>
> 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.
>
>
--
View this message in context: http://www.nabble.com/wicket-vs-vaadin-clarifications-tp24353170p24409410.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket vs vaadin clarifications
Posted by Joonas Lehtinen <jo...@itmill.com>.
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
--
View this message in context: http://www.nabble.com/wicket-vs-vaadin-clarifications-tp24353170p24356576.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket vs vaadin clarifications
Posted by nino martinez wael <ni...@gmail.com>.
I completely agree. I think somethings missing though:
Backed up by a corporation:
Should be ticket, ASF are a corporation.
The comparison seems biased, or influenced by poor knowledge at least
about wicket. Could it be that vaadin wants to sell their product :)
And one thing more to add to:
Widget diversity & richness
You can out of the box make your components update able by ajax
(without ever touching ajax) just by doing plain java.
2009/7/6 francisco treacy <fr...@gmail.com>:
> Hi all,
>
> After I tweeted a criticism about http://vaadin.com/comparison table,
> some employees/supporters quickly got back to me asking to elaborate
> on the problems.
>
> I thought it would be good to make it clear and post it to this
> mailing list. Feel free to comment on my points.
>
> Dear Vaadin people:
>
> 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. 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="..."/>
>
> Framework extensions are done in Java:
> - You should tick it - extensions *are* done in Java
>
> No HTML required:
> - It depends. There are components that don't have associated markup.
>
> No XML configuration required:
> - You should tick it - no XML configuration is required whatsoever. Of
> course, web.xml but... you know.
>
> 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.
>
> Commercial support & guarantees available:
> - There are various companies that provide support for Wicket
>
>
> Francisco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org