Comments on: Writing a Wicket Article http://martijndashorst.com/blog/2005/05/30/writing-a-wicket-article/ Ramblings on Java, Wicket, cats and other stuff Mon, 01 Dec 2008 18:10:06 +0000 http://wordpress.org/?v=2.5.1 By: Jonathan Locke http://martijndashorst.com/blog/2005/05/30/writing-a-wicket-article/#comment-189 Jonathan Locke Tue, 31 May 2005 09:05:26 +0000 http://martijndashorst.com/2005/05/30/writing-a-wicket-article/#comment-189 Got this post via Google alerts today (kinda nifty thing they have there!) I think it's important to dispel the notion that Wicket is just Tapestry without XML. I believe Wicket's component model and particularly its way of doing state management is subtantially different from - and I'd like to think largely better than - competing frameworks... even if I do hesitate to compare it in detail with frameworks like Tapestry or JSF (since I have insufficient knowledge about these frameworks to make a worthwhile comparison). Avoiding XML config files is/was one of the easiest goals to convey, but actually one of the least important motivations in designing Wicket. What mattered most was really the quality and focus of the component model design itself and in particular finding a better/easier approach to state management that still scales. I think it is this work that's going to ultimately attract attention once people really sink their teeth into it. Unfortunately, it will be very hard to capture this in a "soundbite" (or even a 2,000 word article). I think it is a problem that the quick and easy tag people are pinning on Wicket is "Wicket is Tapestry without XML config files". This is easy to say but I think also inaccurate and dismissive because it omits a whole host of important but subtle differences and advantages which are not so easily conveyed. Anyway, I think it will be pretty tricky to boil down what distinguishes Wicket to 2,000 words or so and doubly tricky to compare it to other frameworks like Tapestry in that same article. I suspect that Matt is correct that a comparison of implementations of an example problem would be the best approach. Then people can sort of see what makes it different instead of hearing people talk about it. The risk in talking about it instead of showing it is that Wicket may end up getting tagged with a trivializing soundbite and a lot of people might miss out on something good. Got this post via Google alerts today (kinda nifty thing they have there!)

I think it’s important to dispel the notion that Wicket is just Tapestry without XML. I believe Wicket’s component model and particularly its way of doing state management is subtantially different from - and I’d like to think largely better than - competing frameworks… even if I do hesitate to compare it in detail with frameworks like Tapestry or JSF (since I have insufficient knowledge about these frameworks to make a worthwhile comparison).

Avoiding XML config files is/was one of the easiest goals to convey, but actually one of the least important motivations in designing Wicket. What mattered most was really the quality and focus of the component model design itself and in particular finding a better/easier approach to state management that still scales. I think it is this work that’s going to ultimately attract attention once people really sink their teeth into it. Unfortunately, it will be very hard to capture this in a “soundbite” (or even a 2,000 word article).

I think it is a problem that the quick and easy tag people are pinning on Wicket is “Wicket is Tapestry without XML config files”. This is easy to say but I think also inaccurate and dismissive because it omits a whole host of important but subtle differences and advantages which are not so easily conveyed.

Anyway, I think it will be pretty tricky to boil down what distinguishes Wicket to 2,000 words or so and doubly tricky to compare it to other frameworks like Tapestry in that same article. I suspect that Matt is correct that a comparison of implementations of an example problem would be the best approach. Then people can sort of see what makes it different instead of hearing people talk about it. The risk in talking about it instead of showing it is that Wicket may end up getting tagged with a trivializing soundbite and a lot of people might miss out on something good.

]]> By: Dan http://martijndashorst.com/blog/2005/05/30/writing-a-wicket-article/#comment-188 Dan Tue, 31 May 2005 03:51:28 +0000 http://martijndashorst.com/2005/05/30/writing-a-wicket-article/#comment-188 Don't worry about giving stuff away that you'll also use in the smackdown. Both should present the best arguments... Don’t worry about giving stuff away that you’ll also use in the smackdown. Both should present the best arguments…

]]> By: Martijn Dashorst http://martijndashorst.com/blog/2005/05/30/writing-a-wicket-article/#comment-187 Martijn Dashorst Mon, 30 May 2005 22:39:27 +0000 http://martijndashorst.com/2005/05/30/writing-a-wicket-article/#comment-187 I think that before I can argue that Wicket is bigger, larger, uncut than ... (insert favorite framework here), the readers need to know what Wicket is. How many people have actually heard/read about Wicket? And even more, how many have actually heard/read about component based web development? BTW I want the article to be out there before JavaOne, so I don't want to give away too much for the Web Framework Smackdown in which Eelco is participating. However, if someone wants to start already ... I'm game... I think that before I can argue that Wicket is bigger, larger, uncut than … (insert favorite framework here), the readers need to know what Wicket is. How many people have actually heard/read about Wicket? And even more, how many have actually heard/read about component based web development?

BTW I want the article to be out there before JavaOne, so I don’t want to give away too much for the Web Framework Smackdown in which Eelco is participating. However, if someone wants to start already … I’m game…

]]> By: Matt Raible http://martijndashorst.com/blog/2005/05/30/writing-a-wicket-article/#comment-186 Matt Raible Mon, 30 May 2005 18:03:48 +0000 http://martijndashorst.com/2005/05/30/writing-a-wicket-article/#comment-186 If Wicket is just another component-based framework like JSF and Tapestry, how is it better than those two. Why should I use Wicket over Tapestry? Maybe even some code comparisons. If Wicket is just another component-based framework like JSF and Tapestry, how is it better than those two. Why should I use Wicket over Tapestry? Maybe even some code comparisons.

]]> By: Les Pruszyski http://martijndashorst.com/blog/2005/05/30/writing-a-wicket-article/#comment-185 Les Pruszyski Mon, 30 May 2005 17:32:47 +0000 http://martijndashorst.com/2005/05/30/writing-a-wicket-article/#comment-185 Great to know you are working on an article about Wicket. I think I appreciate your concerns. Maybe the best way to introduce Wicket would be to develop Jonathan Locke's Wicket design principles. Wicket is the best OO framework I've seen and it should be presented as such. Great to know you are working on an article about Wicket. I think I appreciate your concerns. Maybe the best way to introduce Wicket would be to develop Jonathan Locke’s Wicket design principles. Wicket is the best OO framework I’ve seen and it should be presented as such.

]]>