Comparing Wicket and Vaadin

Hi!

Right of the bat…i LOVE Vaadin! I’ve been using it since it was still IT Mill Toolkit, actually i still am, didn’t have the time to upgrade…

Well anyway, I’ve decided to compare Vaadin and Wicket, but not subjectively. So only objective metrical comparisons can do. I’ve looked around for something meaningful to compare, but besides memory consumption and browser support, i can’t think of any more metrics (e.g.:number of ui components doesn’t cut it since you have option for custom components… maybe only out-of-the-box components but that’s another story)… And since I know you guys care about Vaadin and its comparison to other RIA frameworks (I ran into jonas or some other vaadin dev dude on almost every forum, blog, article there is about java web frameworks) I’ve decided to come here for help:)

I am also about to develop two same-specs applications: one in Vaadin and one in Wicket, and test them with those metrics.

so, please, brainstorm for me:) what would make sense to measure about developing/running same application in Vaadin/Wicket.

thanks! Will post results in 1-2 weeks time when i’m done with it.

Hi,

I don’t know if this is of any help, but there is a Vaadin vs. ICEfaces comparison article in our wiki. The main metrics used there were the amount of hours spent in development and the number of lines in the resulting code.


Comparing Vaadin with Icefaces

Anyway, I’m looking forward to your results. :slight_smile:

Great to hear that you are interested in building a metric.

Some objective (technical) measurements that come into my mind include:

  • For a given realistic use-case, measure the number of bytes transmitted down the wire when the user has not used application before (nothing in browser cache)

  • For a given realistic use-case, measure the number of bytes transmitted down the wire when the user has used application before (all cacheable resources in browser cache)

  • Number of code lines for java -code developer has to write

  • Number of code lines for html -code developer has to write

  • Number of code lines for css -code developer has to write

  • Number of code lines for javascript -code developer has to write

Some challenges for testing:

  • How to create comparable implementations: how to ensure that one of the implementations is not less finished looking or have less features

  • How to select the features to use. Say - you decide to use Vaadin Table and like drag-n-dropping re-ordering of columns. If Wicket does not happen to have such feature out of the box - Wicket application implementation would be potentially really hard. On the other hand - if you just select to use features available in both frameworks, it gives a false picture - as no credit is given for having those features in the first place.

I’m almost done with my implementations and i must say:

are proving to be pretty valid thoughts. i tried to use best match of wicket component counterpart to vaadin component, but there were quite some areas where is still a close-call. i know if i leave any room for that debate, that i’ve done framework X some injustice, there will be a storm of supporters of that framework, trying to burn me alive:)

but as far as data models go, i had less trouble figuring out how to correctly use vaadins. wickets is still giving me some trouble…

now, to the point. i’ve been searching the human collective called google for some useful tool to measure download time, render time, download size and stuff like that, but i’m coming up short. tried already: firebug, speedtracer (chrome plugin), YSlow (some yahoo firebug add-on), jmeter…
What do u suggest? could it be that any of those are truly valid and i’m just not using them correctly? Joonas i came across one of your presentations (the one where you try to prove a point about vaadin’s scalability by using live example on world-wide cinema selling tickets). i think i saw you flashing some results there. what tool did u use to get those results?

thanks!

Some of the measurements were done with Apache JMeter and some with a custom scalability measuring application based on HttpUnit. Both only measured the time consumed on server-side + network.