Can we perhaps take this conversation to a wiki page (feel free to continue here, but for those who contribute it'd be nice if they added their $0.02 to a wiki)? I would love to be able to send our management to a page where all of these "stories" are listed. It would be great to have a "Testimonials" section on the Wicket Wiki!
On Wed, Aug 6, 2008 at 3:07 PM, Scott Swank <[EMAIL PROTECTED]> wrote: > My company compared several frameworks and settled on either JSF or > Wicket. We then had a 2 week development effort implementing the same > proof-of-concept app with 2 teams of 4 devs each. Everyone was at > least somewhat familiar with JSF, while only one person in our > department had ever worked with Wicket. > > After 1 week the Wicket team was done, while the JSF team was > struggling over whether to use facelets or jsp for rendering, which > rendering implementation to use, which ajax library to use (and how > that required re-deciding some of the previous items). Now many of > those problems that plagued the JSF team are one-time decisions that > are not indicative of day-to-day development. That said, every > developer who worked with Wicket ended up advocating for it as our web > framework, even though most of them had initially preferred JSF. > > In fact, after seeing the Wicket & JSF code side-by-side most of the > devs on the JSF team voted for Wicket, as did the rest of the > department. > > In the previously recommended article > > http://ptrthomas.wordpress.com/2007/05/14/a-wicket-user-tries-jsf/ > > go down to [The "List Forums" Screen] and compare the JSF tags with > the Wicket html. We can hire presentation-layer developers who only > need to know html & css. > > Also, go into a working Wicket page and screw up something (misspell a > wicket:id, whatever). Now examine the exception you get. It will > likely describe in rather clear terms what is wrong. Now try this > with JSF. Now take your problem and post it to the Wicket forum > (perhaps with a different e-mail address) and ask for help. Now try > that with JSF. > > Scott > > > On Wed, Aug 6, 2008 at 11:30 AM, Peter Thomas <[EMAIL PROTECTED]> wrote: >> Hi, >> >> Here is a list of bullet points I compiled on "JSF when compared with >> Wicket": >> >> – Not really OO components, more of XML tags than Java >> – Added complexity of JSF-EL and mixing JSP-EL if applicable >> – faces-config.xml : synchronize multiple files for navigation, >> page-centric, string expressions not type-safe >> – Poor separation of concerns / "preview-ability" (in core JSF spec) >> – General consensus that for practical use you have to supplement with >> non-standard extensions -e.g. Facelets, Spring WebFlow etc. >> – Hard to unit test >> – Hard to debug / step-through >> – More dependence on tooling / IDE support >> – Mixing components from multiple vendors problematic especially with AJAX >> – Generated HTML is typically verbose >> – Creating custom components is much harder >> – Slow evolution as it is a specification, now JSF 2.0 is being discussed… >> >> I had this as a back-up slide in a presentation recently (which I ended up >> having to use because of all the questions :) You can find the presentation >> here if you are interested, it is more to do with comparing Wicket with >> action / JSP based frameworks, but may help: >> >> http://ptrthomas.wordpress.com/2008/05/26/migrating-to-apache-wicket-presentation-slides/ >> >> Thanks, >> >> Peter. >> >> On Wed, Aug 6, 2008 at 11:44 PM, Igor Vaynberg <[EMAIL PROTECTED]>wrote: >> >>> On Wed, Aug 6, 2008 at 2:13 AM, nlif <[EMAIL PROTECTED]> wrote: >>> > Prior to posting here, I googled a bit, and found a >>> > few forum-threads and blog posts on this topic, but most are from 1-2 >>> years >>> > ago and in framework years, this may be considered obsolete. >>> >>> actually, imho, this is one of wicket's biggest advantages over jsf. >>> jsf is a standard so it moves very slowly. wicket is a much more agile >>> project and moves much faster. >>> >>> > Also, supposedly JSF has a larger selection of 3rd party components >>> compared >>> > to Wicket. Is this true? how often do you find yourself rolling your own >>> > components and how hard is it to do so in Wicket (and I mean >>> > non-trivial-good-looking-Ajax-enabled stuff). >>> >>> actually i find myself creating components all the time, because it is >>> so damn easy. trivial and non trivial, because wicket uses composition >>> it is not that much harder to create components with complex >>> interactions. >>> >>> sure, jsf has plenty of components out there that offer high level >>> things like data grids, etc, but so does wicket. the difference with >>> wicket is this: >>> >>> the other day i created a productlink component for our application. >>> it is a simple component that builds an anchor that takes the user to >>> the product page. it also adds proper css class based on whether the >>> product is for sale or not and whether it is in or out of stock. >>> >>> so now anytime someone needs to link to a product they simply do >>> >>> add(new ProductLink("link", product)); and attach it to <a >>> wicket:id="link">whatever</a>. the productlink can be embedded inside >>> any other component just as easily and have any other component >>> embedded in it as well. >>> >>> i dont think jsf folks would bother creating anything so fine-grained, >>> because although it is very useful there would be too much overhead >>> and pain involved. >>> >>> the problem is that jsf approaches web application development with a >>> few roles in mind: the application developer and the component >>> developer. the component developer is a smarter person that >>> understands the intricacies of jsf. in wicket we do not assume the >>> separation of roles, so our programming model is consistent and is >>> optimized towards component creation. >>> >>> my two cents >>> >>> -igor >>> >>> >>> > >>> > Many thanks in advance. >>> > >>> > >>> > >>> > >>> > -- >>> > View this message in context: >>> http://www.nabble.com/Comparing-JSF-and-Wicket-tp18847208p18847208.html >>> > Sent from the Wicket - User mailing list archive at Nabble.com. >>> > >>> > >>> > --------------------------------------------------------------------- >>> > To unsubscribe, e-mail: [EMAIL PROTECTED] >>> > For additional commands, e-mail: [EMAIL PROTECTED] >>> > >>> > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
