Difference between Apache Tapestry and Apache Wicket

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.

Leave a Comment