On Tue, May 12, 2009 at 1:00 PM, Neil Curzon <neil.cur...@gmail.com> wrote: > Well, whether a page view is executed in one framework or another, the same > calls into the service layer should be made, and the same persistence > queries should be executed. As long as the frameworks' component lifecycles > are co-operative with the design of your application (big if?), the load on > the other tiers should be constant. I think that the relative cost of simply > throwing some plain HTML together, if it is indeed adding 13+ms to every > request, is relevant. > > But yeah, a more advanced web framework may give you the power to implement > a more efficient solution with less development effort. There is a lot of > grumbling about Tapestry documentation, but Tapestry has Wicket soundly > beaten there.
Thanks! There's lots of room for meta-programming in T5 that isn't present in Wicket. > > All of my page views were done without a session, and it seems that Wicket's > raw performance advantage will only increase when the session comes into > play. I understand that will come at the cost of scalability via clustering > and memory consumption, though. I do agree that there are many details that > need to be taken into account. > I don't follow you here; I don't see a reason why adding a HttpSession to the mix would affect either framework more than the other ... until you hit a cluster, then T5 should (in theory) have an advantage. > The problem is that I can't actually compare a real application in Tapestry > vs Wicket without first implementing that application. And, unfortunately, I > can only choose one framework, and must choose one first. > A common problem. > Neil > > On Tue, May 12, 2009 at 3:23 PM, Christian Edward Gruber < > christianedwardgru...@gmail.com> wrote: > >> >> On May 12, 2009, at 2:47 PM, Neil Curzon wrote: >> >>> I think it should be possible to reason about the web framework >>> independently from the back end. >>> >> >> >> However it just ain't so. If the front-ends had equivalent architectural >> impact, then sure. Or if everything were serial, then sure. However, a >> front end can behave differently with minimal back-end activity vs. a high >> degree of back-end activity, simply because it may be able to work or cache >> work product in one scenario that isn't possible in the other, or where the >> margins are so tight that such effort is a higher percentage of the total >> work done. Real end-to-end performance on a request is subject to a lot of >> architectural constraints, when it comes to measuring, and you can't do a >> straight-line computation from a no-op case. >> >> For example, the design of T5 may be such that a page constructed with a >> lot of javascript from different components is handled better than with >> taglibs, since T5 can bundle it up, call it a versioned asset, send it as >> one single compressed stream, and cache it on the client. If the other >> framework handles the JS file-by-file, without compression, and has to >> re-fresh more frequently, then it's possible that T5 can vastly outperform >> the other in a complex application, by design. >> >> cheers, >> Christian Edward Gruber >> christianedwardgru...@gmail.com >> http://www.geekinasuit.com/ >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> > -- Howard M. Lewis Ship Creator of Apache Tapestry Director of Open Source Technology at Formos --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
