We strongly believe in using the right tool for the job. While we currently think of Rails as the de facto choice when it comes to writing webapps, we’ll always consider other options, such as one of the many other Ruby web frameworks, or going with another language such as Python.
Lately I’ve been looking for a chance to play with Grails. Briefly, for those who aren’t familiar, Grails is a web framework that uses the Groovy language – an agile, dynamic language designed for the Java Platform. Grails was meant to use some of the main tenets of Rails (convention over configuration, “Don’t Repeat Yourself”, et al) while using Java web technologies like Spring and Hibernate.
Fortunately, I was finally able to find a chance to play around with Grails – as a simple way of “porting” an existing Java web application to a dynamic language and framework. My reasons were the following, which I’d imagine are true for many other Grails developers:
- The ability to include straight Java code in the project meant being able to re-use existing code, especially if it was not directly related to the webapp. For example, I was able to take a terse image generation function and drop it right into the project.
- Having the framework based on Spring, Hibernate, Acegi and Sitemesh meant there were fewer conceptual changes moving from the old code-base. Working on the code I often felt that I was maintaining the original ideas while reducing the inherent verbosity of Java.
- The previous point applies to the interface code as well – the views in Grails use GSP, which is very similar to JSP and made porting the views almost trivial.
- Moving from another Java framework to Grails requires less of a “sell”. A Grails project packages as a WAR file no different from any Java project. It will have all the positives (and negatives) of a Java app.
So, having used Grails a for a while now, how does it stack up to Rails? Here a few of the things I enjoyed about Grails:
- The GSP tags have the power of JSPs, along with a few features that make them simpler. They’ve also added some tags that don’t have equivalents in JSP, and are quite nice. In particular, I liked using the “sortableColumn” tag, which generates columns in tables that handling sorting. This is something I would like to use in Rails.
- Grails does not currently use migrations (schemas are generated from field declarations in model objects), and while for some projects this could be an issue, it made development that much faster to add a few fields and have the database automatically be updated.
- By default Grails uses a messages.properties file that contains message codes like validation errors and other generic error messages. In some ways it’s nice having all these messages in one place. Also, the validation errors use a default message per constraint type, which can then be overridden.
As well as some caveats (I won’t go so far as to say “problems”):
- Grails uses some different terminology than Rails. Models are “domain classes”, validations are “constraints”, and so on. Not much of an issue, but it may take some getting used to.
- The form helpers in views are not as sophisticated as Rails. Less boilerplate code is generated for you, and more thought has to be put in to maintaining states and values of form elements.
Of course, there’s nothing that Grails does that couldn’t be done in Rails with a bit of extra code or a plugin, and I’d imagine for the most part this is true for Grails as well, so it’s really more about simplicity and core conventions. I’m still working on the port, so I’ll be sure add updates as I get more experience.