Grails, Sails, and Trails – Rails Through a Coffee Filter

This JavaOne 2007 Bird of a Feather (BOF) session seemed like a brief history of web application development. In the beginning there was pain. In the second day XML moved forth. And on the last day there was Rails, and developers thought it was good. Ruby on Rails’ most mentioned philosophical innovations include Convention Over Configuration, Don’t Repeat Yourself, Opinionated Software, Test Driven Development, and the 80/20 rule. The 80/20 rules indicates that Rails is not all things for all web developer. Rails does one thing and it does CRUD applications well.

Rails growth coincides with the disillusion of EBJ 2.x, and the painful write, compile, deploy, and restart cycle.

Sails models leverage Hibernate, view uses custom template engine Viento, and the controller is rigged using custom dependency injection library which provides Convention Over Configuration. The Viento templating system provides Ruby-like features such as method missing, mixin, and reopening classes.

The second Java-based framework heavily influenced by Rails mentioned during this session was Trails. In addition to Rails, Trails was influenced by the Naked Object pattern, and domain driven design. Trails uses Tapestry, Spring, Hibernate, and Maven to tie everything together.

Grails was originally named Groovy on Rails and as such it was heavily influenced by Rails’ Convention Over Configuration, MVC, dynamic finders, and agile web development. Grails is powered by Hibernate, Spring, Sitemesh, Quartz, and the Groovy programming language.

A key benefit of Grails models over Rails models is that your model does not need to inherit some ORM ActiveRecord-like class, like in Rails. Grails embraces legacy enterprise systems with more complex relationships by leveraging Hibernate. Grails allows you to configure Hibernate and Spring when needed. A possible draw back, depending how you see it, is that in Grails you need to declare the properties in your model which will be mapped to your database table.

Groovy code compiles down to Java byte code. A Groovy class is a Java class, and vice versa.

According to the speaker both Trails and Sails don’t solve enough pain points while Grails is worth a shot. It is worth to note that as soon as some performance improvements have been made, JRuby on Rails will soon be a legitimate platform for your next web application. The benefits of Rails is that there are more books, more documentation, more inertia, and perhaps more developers for Ruby on Rails.

Technorati Tags: , , , , , , , , ,

3 Responses to “Grails, Sails, and Trails – Rails Through a Coffee Filter”

Leave a Reply