Question

Apache Wicket ( http://wicket.apache.org/ ) and Apache Tapestry ( http://wicket.apache.org/ ) are both component oriented web frameworks – contrary to action based frameworks like Stripes – by the Apache Foundation. Both allow you to build your application from components in Java. They both look very similar to me.

What are the differences between those two frameworks? Has someone experience in both? Specifically:

• How is their performance, how much can state handling be customized, can they be used stateless?
• What is the difference in their component model?
• What would you choose for which applications?
• How do they integrate with Guice, Spring, JSR 299?

Edit: I have read the documentation for both and I have used both. The questions cannot be answered sufficently from reading the documentation, but from the experience from using these for some time, e.g. how to use Wicket in a stateless mode for high performance sites. Thanks.

Answer 1

Some relevant differences as I see them:

• Tapestry uses a semi-static page
  structure, where you can work with
  conditionals and loops to achieve
  dynamic behavior. Wicket is
  completely dynamic; you can load
  components dynamically, replace them
  at runtime, etc. The consequences of
  this are that Tapestry is easier to
  optimize, and that Wicket is more
  flexible in it’s use.
• Both frameworks
  are roughly equally efficient in
  execution, but Wicket relies on
  server side storage (by default the
  current page in session, and past
  pages in a ‘second level cache’ which
  is default a temp file in the file
  system). If that bothers you, think
  about how many concurrent sessions
  you expect to have at peak times and
  calculate with say ~100kb per session
  (which is probably on the high side).
  That means that you can run roughly
  support 20k concurrent sessions for
  2GB. Say 15k because you need that
  memory for other things as well. Of
  course, a disadvantage of storing
  state is that it’ll only work well
  with session affinity, so that’s a
  limitation when using Wicket. The
  framework provides you with a means
  to implement stateless pages, but if
  you’re developing fully stateless
  applications you might consider a
  different framework.
• Wicket’s goal is to support static typing to the fullest extent, whereas Tapestry is more about saving lines of code. So with Tapestry your code base is likely smaller, which is good for maintenance, and with Wicket, you much is statically typed, which makes it easier to navigate with an IDE and check with a compiler, which also is good for maintenance. Something to say for both imho.

I have read a few times by now that people think Wicket works through inheritance a lot. I would like to stress that you have a choice. There is a hierarchy of components, but Wicket also supports composition though constructs like IBehavior (on top of which e.g. Wicket’s Ajax support is built). On top of that you have things like converters and validators, which you add to components, globally, or even as a cross cutting concern using some of the phase listeners Wicket provides.