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]
