I recently stumbled across a blog post by Kalle Korhonen: Why Tapestry?. Kalle has been very busy with Tapestry as the force behind Tynamo, a RAD toolkit built on top of Tapestry.
On the subject of performance:
the performance of the framework itself, both in terms of CPU and memory consumption, is simply phenomenal. Performance matters.
On how Tapestry compares with the competition:
What I really like to give as an answer to people who ask why one should use Tapestry is this: because it is well-balanced and comprehensive.{excerpt} There are a lot of other web frameworks that are optimized with a certain thing in mind and in that narrow field, they typically beat the competition. It's difficult though to be a good all-around contender but that's exactly what Tapestry is all about.
On the effectiveness of Tapestry as a solution:
Today's Java is far from your grandfather's Java a few years back and Tapestry makes the best use of the more advanced, modern JVM techniques available today, such as bytecode manipulation, annotation-based meta programming and introspection without reflection. Tapestry code is purposefully remarkably succinct.On how Tapestry enables modularity:
Perhaps we've gone a bit overboard with modularity, but since it's just that simple with Tapestry, most of our modules are independently usable but seamlessly work together in the same web application as soon as you add them to the classpath.
There's quite a bit more, and it is both favorable to Tapestry and well balanced. Read the full posting.
4 comments:
Tapestry is such a pleasure to work with. I've recently been doing work with JSF, GWT, & JSP. And I'd say Tapestry makes me most productive and let me code more efficiently. Thanks Howard.
I was a bit puzzled by the "introspection without reflection" phrase: I would really appreciate if you could expand a bit more on this topic....
@Marco
I'm confused by that as well; Tapestry does a limited about of reflection to analyze properties (in fact, building off of the Java Introspector). I think what he was trying to say is that the property expressions are converted to bytecode rather than relying on reflection. LIkewise, the way T5 proxies work is based on bytecode, rather than JDK Proxy support and InvocationHandler ... the latter having to box and unbox primitives and use object arrays to represent method arguments.
I also like Tapestry *5* very very much, I'm always trying to evangelize my friends that are really sceptic about it's advantages.
But someday this will change.
Post a Comment