Lately, I’ve had noticeably more people asking me about Tapestry and why one should choose it over the other (Java) web frameworks. To me, Tapestry is a good compromise, just like Java is. Linus Torvalds, my fellow country man, has famously said “performance almost always matters”. There are so many aspects to web development, and performance is often seen as one of the smallest of your problems because in the end “it always comes down to the database”. However, a high performing framework solves many other problems. Today, a typical, reasonably well-implemented Java web application on a modest hardware can serve hundreds of concurrent requests, thousands of concurrent users and tens of thousands of users a day from a single server. Most start-ups never need to worry about the scaling out problem until they actually have the money to pay for it. Unfortunately, you can also easily make the implementation horribly slow, suffering from scalability problems from the get-go and even more unfortunately, it’s easier to go wrong with some Java frameworks than with others. For what Tapestry offers, the performance of the framework itself, both in terms of cpu and memory consumption is simply phenomenal. Performance matters.
However, I really don’t want to make this post about Tapestry’s performance. As soon as you mention one thing about a particular framework, people tend to place it in that category and forget about everything else. 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. 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. Tapestry doesn’t force you to a certain development model - such as using sessions, always post, single url, ajax-only, thick RIA etc. If you just need to handle a specific case, such as building a single-page, desktop-like application for web, you could pick GWT, Flex or Vaadin, but if you are a building a generic, mixed static/dynamic content site with multiple pages you’d undoubtedly pick entirely different set of tools. Tapestry though, is an “enabling” technology - you could use it together with all three aforementioned RIA frameworks. You could also use and people have used Tapestry-IoC alone in non-web desktop applications. Not a whole lot of other “web” frameworks can claim suitability for such diverse use cases. Sadly, comprehensiveness of a framework can be a somewhat difficult area to objectively compare so each framework usually resorts to toting their best features to prove their superiority over others.
One criteria I personally use a lot in comparing effectiveness of competing solutions is their expressiveness and succinctness. Now, everybody knows that Java is a butt-ugly language (though it makes up on other departments, like performance and comprehensiveness). 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. Minimal effort required for creating Tapestry components makes it easy to refactor your application logic into reusable elements, rather than having to repeat yourself. Patterns in object-oriented languages are a well studied and accepted principle, but only a few (IoC) frameworks besides Tapestry IoC manages to have a framework level support for implementing common ones, such as chain of command, strategy and pipelines.
For Tynamo, I’ve said it before but I just don’t think we could have achieved the same CRUD functionality with any other framework. Certainly anything can be done, but the cost of it would have both been far higher and we would have needed to build much more infrastructure. When we moved from Tapestry 4 to Tapestry 5 (and from Trails to Tynamo), it was amazing to see how we were able to simplify our implementation and remove huge amounts of code while keeping the concept unchanged and making it all more modular at the same time. Using a different stack, you could probably get closest to what tapestry-model is with a combination of Wicket and Spring, but allowing the same level of extensibility would undoubtedly be more cumbersome. Back in Trails, we actually had one person working on a pure Spring (MVC + core) implementation of the same concept but it died a slow death. As the documentation states, tapestry-model produced “default model is highly customizable, you can change pretty much anything you need, and make the changes specific to type, page or instance - a feature that very few other CRUD frameworks offer”. The big difference is that when you need to customize the model, you don’t have to rewrite it all, you’ll be just customizing the pages and overriding components as needed.
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. Today, Tynamo is much more than just tapestry-model, the CRUD framework. Tapestry-security, tapestry-conversations and tapestry-resteasy are all steadily gaining popularity and based on the page views, it seems that tapestry-security is poised to become our most popular module offering at some point. On that note, I have a few new supplemental modules for tapestry-security coming up which should be of interest to others as well, but more on that in a separate post. For now, I hope I’ve been able to give some answers to why at Tynamo, we think we’ve made the right choice with Tapestry and I’m confident that 2011 will be the best year yet both for Tapestry and Tynamo!
