On Thu, Aug 7, 2008 at 12:24 PM, nlif <[EMAIL PROTECTED]> wrote: > > Peter, > > Actually, when I said I googled a bit and found some material, I was in > fact > referring to your blog post and the slides :) This is very useful > information, and your comparison was done, IMHO, very fairly and > skillfully. > However, as I said, this is from 2006, and I figured things may have > changed. Obviously, Wicket has matured and improved, but for all I know - > so > did JSF probably. > > Are you still up-to-date with JSF nowadays? Would you still hold to the > same > opinion based on current offering of both frameworks? > > Thanks, > Naaman > > Naaman,
Sorry for replying a little late. Actually the comparison you are referring to was done in mid 2007 not 2006 - so I don't think it is *that* out of date. I still do try to keep track of JSF but not hands-on. With respect to the JSF 1.1 code in the blog-post (which is a very simple example), I am not aware of anything new in JSF 1.2 that would improve any particular aspect. There were a few pro-JSF comments saying that Facelets would address the lack of "previewability", and it is true that I stuck to core JSF for the comparison. Facelets and today Spring WebFlow appear to offer some respite from what many see as significant limitations in the spec - but if you choose to go down that path, one of the main arguments for using JSF does not hold good anymore. Which is of course, the tired old argument that "JSF is a standard". So if you look beyond the core spec - you now have a big choice to make, for instance do you want to go the Sun / Facelets way, the JBoss Seam way, the Spring way or the high-way. This is what JSF advocates cunningly refer to as an "ecosystem". As an example of where the current version of the spec has limitations - JSF 1.X was obviously drafted in an age where Ajax was unheard of. The pro-JSF arguments with respect to Ajax are that JSF is designed for extension and you just have to hook into the life-cycle phases etc. To me this honestly sounds more like a workaround, and there are comments on the above mentioned blog post that speak of javascript library collisions when you mix components from multiple JSF vendors. Let me just say that in over one and half years of developing (at least three different applications) with Wicket, I am yet to see a situation where the stuff I want to do in Ajax is restricted in any way by the framework design or anything like that. Seriously. Coming to JSF 2.0 it is anybody's guess as to when that community process (read: design-by-committee) will get over and when usable implementations will start appearing. Life is too short and I prefer being intensely productive rather than waiting for a promised spec and enduring the pain and sleepless nights while the "ecosystem" stabilizes. Generally specifications like JSF gravitate towards a "least common denominator" approach. I'm not saying that there is no place for standards, but especially when building user interfaces, you will agree that every client is different and demands a different approach. One thing that even JSF advocates will admit is that it is hard to create custom components. So if you hit a wall and find that an existing JSF component needs to be tweaked for your project, you are at the mercy of the component vendor or you have to customize the component yourself. JSF makes an IMHO flawed assumption that the committee has done the Big Design Up Front to cover all use cases and context variations. Case in point: just take this example of a simple autocomplete component [1]. Look at all the possible attributes that this component supports. To me, this smells strongly of YAGNI [2]. Thanks, Peter. [1] https://blueprints.dev.java.net/complib/v2/auto-complete.html [2] http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It ptrthomas 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 > >> wicket:id="link">whatever . 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] > >> > >> > > > > > > -- > View this message in context: > http://www.nabble.com/Comparing-JSF-and-Wicket-tp18847208p18865081.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] > >
