Re: Voice of dissent, was (Re: Tapestry vs Struts)

[Glen Stampoultzis <gs...@iinet.net.au>]

Nice balanced post I thought.

Regarding performance I'd love to see some numbers.  From some very basic 
testing I did it seemed to be scaling okay but the tests were too basic to 
really get a good feel for it.

Regards,

Glen

At 04:41 PM 29/01/2004, you wrote:
>Hi all,
>
>Ovidiu wrote:
> > to put it simply , Struts just sucks and Tapestry rocks
>
>I'm not a Struts expert, but I know a thing or two about Tapestry, and 
>although Tapestry does rock this kind of mindless Tapestry worshiping is 
>getting on my nerves.
>
>So I'm about to be the Voice of Dissent in this mailing list and list some 
>of Tapestry caveats, they are not new to those who develop Tapestry 
>applications, but I will enumerate them for the benefit of those who don't.
>
>* Steep learning curve. Not a problem for me anymore, but I've to deal 
>with it nonetheless. Every time new members join the team I find myself 
>explaining the "Tapestry way" of web-development. It wouldn't  be much of 
>a problem if not for caveat #2
>
>* Tapestry is not widely accepted. This means that is hard to find people 
>who don't equate Tapestry knowledge to taffeta skills.
>
>* Even though there are 8 developers on the Tapestry Dev team[1], it's 
>clearly a one man show (Howard). This wouldn't be much of an issue if it 
>weren't for the "Whatever Howard says it goes" mentality, sometimes I have 
>the feeling that the rest of the Dev team job is to be cheerleaders. I 
>know I'm being unfair, but I'm trying to make a point :-)
>
>"Why is this a problem?" I hear you ask... well... for the last months 
>Howard has been busy with the book writing/changing jobs/changing home/a 
>myriad of other life's issues, and Tapestry development entered "slow 
>motion" mode. This gives me pause, I find myself wondering if there is 
>life for Tapestry after Howard. I don't doubt Howard's commitment to 
>Tapestry, the personal and professional sacrifices he made to this project 
>speak for themselves, but we all know that "shit happens".
>
>Another thing is that Howard subscribes to the "development is like 
>gardening" and "coding is like sculpting"[2] way of thinking, Whether 
>these analogies are correct or not, it's not the point. The point is that 
>this way of thinking left loose without pragmatical opposition, leads to 
>"let's make something really elegant, and really clever, let's make it 
>possible for users to express their intentions and we magically produce 
>the code... yeah let's use byte code trickery, yeah let's do that"... and 
>this is another caveat all by itself.
>
>* Byte code magic working under the covers. Personally I like to keep to a 
>minimum the number of things (hidden| I can't control | I don't 
>understand), but this could be palatable if the magic worked without 
>problems, it doesn't. I've experienced weird|unreproducible debug errors, 
>weird|unreproducible class enhancement errors and security settings 
>headaches. To my mind there is not much point in saving development time 
>if two months down the line I have to spend hours trying to figure out 
>what in the hell is going wrong.
>
>* Tapestry is very resource intensive. No one else ever complained about 
>this in the mailing list, so this must be a pet peeve of mine. My team 
>converted (and are in the process of converting) most of our internal 
>applications to use webfrontends developed with Tapestry. These are 
>basically CRUD apps, the users (~2500 of them) are not dwelling on each 
>page, they have sub-second reactions and they want/expect sub-second 
>responses. In this environment Tapestry apps consume CPU cycles like 
>there's no tomorrow.
>
>* The performance penalty of setting "org.apache.tapestry.disable-caching" 
>property to "true" is much to severe to such a useful setting.
>
>* The URLs generated by Tapestry are a mess, and doing a "hierarchy layed 
>out" site is not straight forward. Why do I care about the URLs? I usually 
>don't, but there are times where "good looking" URLs are useful, e.g: 
>recently one of our customers wanted to know which part of his site was 
>getting more views, and the obvious solution of parsing the server access 
>logs doesn't work so well.
>
>* Tapestry applications are "session happy", if you so much look at them 
>funny you create a session (a Visit object in Tapestry terms).
>
>* Another one of my pet peeves is that there isn't a straight forward way 
>of implementing response caching, and if you want to do it prepare to deal 
>with Tapestry's internals more than you may desire.
>
>
>Reading the above it may sound that I don't like Tapestry, the opposite is 
>true.
>
>I once was as VB/ASP developer, Tapestry is *the* reason I'm a Java 
>developer today, albeit not a very good one.
>
>So, I like it a lot. Despite the above mentioned issues, I think Tapestry 
>is the best web framework out there, there's no contest, all the others 
>I've tried aren't even in the same zip code, and I have a huge debt of 
>gratitude to Howard and the rest of the Tapestry team (sorry about what I 
>said above guys, I was using rhetoric exaggeration, I hope that was clear).
>
>Tapestry is excellent, I wish it was better though.
>
>Regards,
>Luis Neves
>
>[1]-http://jakarta.apache.org/tapestry/dev.html
>
>[2]-http://www.jroller.com/page/hlship/20030625#coding_in_many_dimensions
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>


Glen Stampoultzis
gstamp@iinet.net.au
http://members.iinet.net.au/~gstamp/glen/