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. 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. 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. 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 > >
