Why Consider Grails?

Not Another Rails . . .
When I first heard about Grails, I really wasn't that interested. I spent some time evaluating Rails a while back, and from Ruby's rather perl'y syntax to the relatively new framework code, I understood why it was popular, but it just wasn't quite what I was looking for. When I first heard about Grails I assumed it was just a Rails clone in Groovy and frankly that wasn't very exciting to me. However, recently I took a little bit of time to look at Grails and I'm pretty excited about the promise - especially from a 1.1 technology (as I write this, 1.1 is in release candidate 1 and I'm using that for all of my experimentation).

A Solid Foundation
For me, the most exciting thing about Grails is that it's native to the Java stack. While you can run Rails on JRuby, it is not designed specifically for the JVM. Grails is written in a combination of native Java and Groovy and is designed from the ground up to take advantage of proven frameworks like Hibernate for managing persistence concerns and Spring for everything from dependency injection and AOP to web flows (wizard style multi-step stateful processes).

The Customization Curve
I'm pretty involved with Domain Specific Modeling and DSL's. One of the biggest issues with raising the level of abstraction of your application development through DSLs is that if you're not careful you run into customization cliffs where one small change outside of the parameters of the DSL requires you to move to a much lower level of abstraction, making "simple things easy and difficult things almost impossible" :-) What I like about Grails is that the dev team have clearly thought carefully about creating a more granular customization curve where there are a number of steps each of which provide a little more control in return for a little more work.

For example, by default, the dynamic scaffolding gives you a very simple way to manage your domain objects. If they don't quite meet your needs, Ant tasks allow for the generation of clean, succinct scaffolding code which you can then customize further. Also, you can write most of your code in Groovy (an elegant, dynamically typed "low ceremony" language that runs on the JVM), but if you need to provide more information than Groovy requires you can progressively enhance your Groovy with additional typing and other annotations until (if you want) you can finally just code chunks of your application in Java - with seamless back and forth calling between Java and Groovy objects (because the Groovy objects just compile down to POJOs using a set of sensible defaults that are pretty easy to override).

Nothing Comes for Free
Of course, the power of a Java based web application comes at a cost. Typically a Java web app will consume more memory under low loads than a similar app written in (say) PHP. So if you're looking to pack 200 applications onto a single server, unless you do something clever where they share a single instance cleanly, Grails might not be the best fit. Equally, hosting for java servlet containers can be a little more expensive than entry level PHP hosting, But if you're looking to create applications and to be able to use the same tooling for building everything from a quick content management system to a really sophisticated enterprise app, a Java based deployment can make a lot of sense.

Conclusion
If you're using a Java stack (or are open to doing so), right now is a great time to look at Grails. It provides intelligent defaults which are easy to override, a good templating system, an excellent DI framework and the reference ORM implementation. There are many good IDE's (although for my money $250 for an IntelliJ IDEA license is a no brainer), and the number of books, blog postings, articles and other resources is just starting to take off.