47

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.

Jonas
  • 121,568
  • 97
  • 310
  • 388
KingOfCoders
  • 2,253
  • 2
  • 23
  • 34
  • JFYI, I have revised my answer a lot. – Sergey Apr 15 '09 at 11:10
  • 7
    I would personally avoid Tapestry for the reason that its tends to get completely rewritten with every major release, and it's rarely backwards compatible with previous versions. – skaffman Aug 06 '09 at 16:47
  • 8
    As of version 5 this should not longer be an issue - version 5 has been built with future extensibility in mind. – Joel Dec 03 '09 at 14:00

8 Answers8

41

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.

Eelco
  • 1,718
  • 22
  • 16
  • "...your code base is likely smaller, which is good for maintenance" -- Are you sure? Experience shows that it's often the opposite. For the same amount of complexity and the same quality of code, a verbose code is usually more maintainable that a terse one. To achieve tersity, you need magic and corner-cuts. – Laurent Grégoire Feb 03 '12 at 10:23
  • @IOranger that can certainly be the case. Depends on how 'smaller code' is supported. Not all magic is bad, but it can certainly backfire. – Eelco Feb 03 '12 at 19:57
36

REVISED after studying Tapestry 5.

Wicket's goal is an attempt to make web development similar to desktop GUI one. They managed to do it really well at the expense of memory usage ( HTTPSession ).

Tapestry 5's goal is to make very optimized (for CPU and memory) component oriented web framework.

The really big pitfall for me was responses "Wicket supports stateless component!" to the arguments "Wicket is memory hungry". While Wicket indeed supports stateless components they are not "a focus of Wicket development". For example a bug in StatelessForm was not fixed for a very long time - see StatelessForm - problem with parameters after validation fails.

  • IMHO using Wicket is a bit eaiser until you are going to optimize/ fine-tune web application parameters
  • IMHO Wicket is harder to study if you have programmed web applications and want to think in terms of request processing
  • Tapestry 5 automatically reloads component classes as soon as you change them. Both frameworks reload component markup.
  • Wicket forces markup/ code separation, Tapestry 5 just give you this ability. You can also use less verbose syntax in Tapestry 5. As always this freedom requires more cautions to be taken.
  • Wicket's core is easier to debug: user components are based on inheritance while Tapestry 5 user components are based on annotations. From the other side that could make transitions to the future versions easier for Tapestry then for Wicket.

Unfortunately Tapestry 5 tutorial does not stress that Tapestry code example like 't:loop source="1..10"...' can be a bad practice. So some effort should be put into writing Tapestry usage conventions/ good practices if your team is not very small.

My recommendations:

  • Use Wicket when your pages structure is very dynamic and you can afford spending 10-200 Kbs of HttpSession memory per user (these are rough numbers).
  • Use Tapestry 5 in cases when you need more efficient usage of resources
Sergey
  • 2,906
  • 3
  • 27
  • 32
  • Thanks, good point, I also think a good speration is important for future maintenance. – KingOfCoders Mar 18 '09 at 15:15
  • Especially if you have a few junior/ undisciplined programmers in your team :) – Sergey Mar 18 '09 at 16:46
  • I've never seen any code in a Tapestry 5 template. How should that work? – Henning Mar 19 '09 at 19:22
  • I see. Well, it's not exactly code, as you must still use components, and a loop is just one of them. But you're right, I also prefer the instrumentation syntax, and maybe the – Henning Mar 19 '09 at 21:05
  • Good work, Sergey! Thanks for that. I was always too lazy to check out Wicket in depth. +1 – Henning Apr 15 '09 at 13:09
  • @Henning, Now I understand the advice to study project mailing list carefully before choosing a framework. I would study Tapestry 5 in the first place if I would follow that. – Sergey Apr 15 '09 at 14:25
  • Don't assume Tapestry is actually more efficient on all accounts. Previous benchmarks showed a very comparable performance. I have personally always doubted Tapestry (4 and below, don't know about 5) object pooling, which in practice may turn out to be more expensive than just creating the objects. Also, state has to go somewhere; just keeping it in memory is vastly more efficient than e.g. externalizing it. – Eelco Aug 27 '09 at 05:43
  • @chillenious, in Tapestry 5 component pooling is essential because T5 component creation is expansive operation. From the other side it makes possible to do elaborate optimizations. For example converting recursive component tree to optimized state machine. That makes difference if you have a lot of components. See http://tapestryjava.blogspot.com/2009/02/speeding-up-tapestry-51.html – Sergey Aug 28 '09 at 11:49
  • 2
    @chillenious, at least with Tapestry 5 you have a choice either to use memory extensively or not. As I understand with Wicket you can only play with where to store user sessions. – Sergey Aug 28 '09 at 11:51
  • 4
    Sergey, to prove my point: see http://ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-5-and-grails/ Even if you discard that is a biased microbenchmark (which I think it isn't), just don't assume, measure. The results there (that Wicket is faster *and* consumes less memory), is consistent with various benchmarks I ran myself and heard of other people running over the years. I wouldn't say the difference is large enough to pick your framework on though; just pick the one that fits your style best. – Eelco Sep 17 '09 at 17:02
  • 2
    > at least with Tapestry 5 you have a choice either to use memory extensively or not. As I understand with Wicket you can only play with where to store user sessions. You can choose where to store just about anything. It's a very flexible framework, especially because it leaves developers in charge of object creation etc. We just don't support client state saving, mainly because when we were half way implementing it, it turned out to be so inefficient (as it is in ASP.NET, JSF, etc) that we didn't think it was worth our effort. – Eelco Sep 17 '09 at 17:05
  • @chillenius, I think the most interesting part in the latter comparison is in the comments. See the 39rd comment by Igor Drobiazko. IMHO the author approach to rewrite the base application very close to the original is not good to measure performance. It's like writing C style programs in Lisp to prove that Lisp is much slower. – Sergey Sep 20 '09 at 17:55
  • @chillenius, I agree that the current T5 docs are not very fine. – Sergey Sep 20 '09 at 17:56
10

Here's a pretty thorough comparison from IBM's Developer Works.

http://www.ibm.com/developerworks/java/library/os-tapestrywicket/index.html?ca=drs

Update: link is dead, but you can find the page on http://web.archive.org/web/20131011174338/http://www.ibm.com/developerworks/java/library/os-tapestrywicket/index.html?ca=drs

valentin_nasta
  • 596
  • 4
  • 23
Scott Swank
  • 664
  • 1
  • 6
  • 7
1

I think Wicket is a simpler framework to use.

Also, Wicket does allow for class reloading via your IDE's hot-code replace system. This is all that is required for Wicket to run off modified versions of a currently running application's classes. The usual restrictions apply for hot-code replace, such as having to run in Debug mode (Eclipse) and not being able to change structural aspects of a class (i.e. class name, changing method signatures etc...).

Antony Stubbs
  • 13,161
  • 5
  • 35
  • 39
1

I don't like the Tapestry programming model and I know of many developers leaving Tapestry because of too much changes and incompatibilities in development. See: http://ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-5-and-grails/

deamon
  • 89,107
  • 111
  • 320
  • 448
0

Try http://incubator.apache.org/click/ . It is amazing java web framework. Some people call it “Wicket made right” ;-)

Andrej Fink
  • 350
  • 2
  • 5
  • 1
    A lot of frameworks claim that, none of them have actually proved to be right yet. Certainly Wicket has done some stuff in absurdingly cumbersome way, but just by copying the best of Wicket does not a better framework make. Also their quick start is more complex than Wicket on step *1* already. – Esko Jan 16 '10 at 10:54
  • After Click quick start you can use Click (write code). After Wicket quick start you have wicket installed - feel a difference? ;-) Click isn't second copy of Wicket. They born near the same time, inspired by Tapestry. 2Stephan: if you like Stripes, you will love CLick, as Stripes book author do: http://stripesbook.org/blog/index.php?/archives/47-New-book-Getting-Started-With-Apache-Click.html – Andrej Fink Jan 16 '10 at 11:09
  • 2
    Wicket QuickStart is a Maven POM creator, Click's QuickStart is equivalent to Wicket's "Hello World" @ http://wicket.apache.org/examplehelloworld.html Also seems like Click doesn't really have `separation of code and markup` which is one of the biggest features of Wicket - in fact Click uses Velocity for the HTML which is a templating language in itself. Because of this Click isn't really component oriented even though it claims to be, it's more close to JSTL or maybe Tapestry in that regard. Also you're clearly advertising which makes me feel uneasy about your post as a whole. – Esko Jan 16 '10 at 17:32
  • 2
    1) For me (and for example for this guy http://www.assertinteresting.com/2009/03/why-i-prefer-stripes-over-wicket/) quick start mean a bit more (quote: if you read the quick start guide, a mere 3 pages or so, you’ll basically “get” Stripes). 2) I'm not so purist, after long time with "raw" servlets+JSP, then servlets+Freemarker, then SpringMVC+Freemarker Click is enough OO and component oriented to me. 3) I like Spring and Freemarker. Click has same "fun" as them both. 4) I'm not affiliated with the Click framework, I'm just a huge fan. – Andrej Fink Jan 18 '10 at 13:23
0

As I said when 4.1 was the official stable release:

You should take a very good look at the development history of Tapestry before committing to use it. Tapestry has done a lot of non-compatible upgrades, with no continuation of support of older versions. Patches to 4.1 are not processed anymore within a reasonable timeframe. That is in my point of view not acceptable for the official stable version.

Committing to use Tapestry 5 means:

you should become a committer; you need to keep up with all new development, abandon old versions as fast as possible; maintain stable versions yourself.

Stephan Eggermont
  • 15,847
  • 1
  • 38
  • 65
0

Wicket is very good web framework. Best from all what i'm know. I'm use it since version 1.3 and always get what i'm want. Wicket has excellent integration with Spring - just use @SpringBean annotation in you code to inject any spring bean to your classes.

Alexey Sviridov
  • 3,360
  • 28
  • 33