On Grails, Trails and Sails

At JavaOne this year, there was a presentation on "Grails, Trails and Sails - Rails Through a Coffee Filter". There's been a few comments on it scattered in various blog posts (at least http://www.juixe.com/techknow/index.php/2007/05/29/grails-sails-and-trails-rails-through-a-coffee-filter/ and http://blog.shinetech.com/?p=18), so it seems fitting to have some reply to it here. As mentioned in the blogs, I had the honor of announcing that I had just weekend before JavaOne tagged Trails 1.0 release.

Overall, I thought Trails faired well against the competition, and while the presenter used several months old version of Trails, he made a decent job demonstrating it. Only Sails doesn't seem like an active project, so mainly it was a comparison of Trails to Grails. The presenter mentioned that Grails is semantically closest to Rails and it's picking up steam compared to others, and that he's not sure if Trails is addressing enough pain-points. Certainly, even the whole Tapestry community is small compared to Struts or JSF, which already has an effect on the number of people interested in Trails or those who've even heard about it. But I'd have to disagree with the latter statement about pain-points. I've always thought that besides helping you to start quickly with your project (which all of these Rails-like projects do), the greatest strength of Trails is that it combines all of these state-of-the art frameworks into one and leverages their strenghts rather than introducing yet another way of doing things, such as the custom presentation layer in Grails. Tapestry has already solved some hard problems, like concurrency issues, caching the templates and re-using presentation objects, which allows us to focus on cases that none of the current web frameworks support: instance-based security, web flows, long conversations and modularizing the framework in order to have built-in support for different persistence layers etc. Currently, Trails uses Tapestry 4.0.2, but we are committed to moving to Tapestry 4.1.2 in Trails 1.1, and when new versions come out, we get the improvements to the presentation layer "for free".

Whenever these comparisons happen, there's always the question whether the separate projects could leverage each others or even merge. It's said many a times that it probably wouldn't have been possible to implement Trails-like framework without Tapestry, and so Trails is dependent on it. There's no way nor need for Trails to change to something else, and therefore couldn't merge with any other project. Similarly, Grails is married with Groovy - the project undoubtedly wouldn't exist without it. Groovy is cool though, and you could technically write Trails/Tapestry code with it, but it wouldn't help any when writing the Tapestry code templates - arguably the hardest but most powerful part of Tapestry. And that's final advantage of Trails: it is a remarkably flat framework, there are no additional layers obscuring you from customizing the application with the techniques available in each framework. So, if you are versed with Tapestry, Spring and Hibernate, it's almost a no-brainer to use Trails for a new web application.