Both Mark and I attended a presentation last night that covered a variety of frameworks inspired by Rails – known collectively as the ‘*rails’ frameworks. Core to all of them is that they promote the convention-over-configuration approach pioneered by Rails.
We began with the grand-daddy of them all: Rails itself. Frankly this was the fourth time at JavaOne I’ve had somebody give me an overview of Rails and whilst in some ways this is indicative of a good thing going on, it was starting to wear a little thin for me personally.
Next, the presenter gave us a 10-minute overview of the Sails framework…before confessing that the project was actually dormant – apparently most of the core developers have gone to Rails. I just wished he’d told me that at the start so I could have done something different with my brain for that 10 minute period.
The third framework covered was Trails. This was an interesting one in that it pulls together Tapestry, Hibernate and Spring in a pre-packaged framework. At the time of the presentation, it was announced that it had just gone to 1.0. However, being based fully on Java it seemed to lack some of the expressive power of frameworks built on more dynamic languages.
Finally, we learnt about Grails, a Rails-like framework that uses Groovy. The chief selling-points of Grails are that:
- Groovy’s resemblance to Java purportedly makes it easier for Java programmers to learn than Ruby.
- Grails integration with Hibernate and Spring means that experience with these frameworks can be leveraged as well.
- It easily integrates with any other Java code that you may have.
Grails provides code generators that are very similar to those provided by Rails. And Groovy’s dynamism allows for a Ruby-like conciseness in your code.
Of the frameworks presented, Grails presents the most feasible alternative to Rails. It’s too early for me to comment in any more detail on it. However, with a few more Groovy and Grails-related presentations to go, hopefully I’ll be in a better position soon to comment.