Grails
Lately I’ve been using Grails at work. The client chose Grails, and it’s my first real exposure to that framework or to the Groovy language.
This might be a little premature, but I’m going to offer some initial thoughts.
What I like
It works
Everything you’d expect from an MVC web framework is there, and you can use it to get the job done.
Convention over Configuration
Not a Grails original, but very nice to have. Grails does a pretty good job of keeping the code maintainable by telling you how to organize it.
WAR files
Grails apps are deployed and administered like Java apps. That’s part of what the client likes, and it’s definitely a big plus for some people.
What I Don’t Like
Not enough documentation, especially in the plugins
Sometimes there’s plenty of documentation, but often enough there isn’t. It’s one thing when a plugin is a simple wrapper around a Java library that has its own documentation or adds some straightforward feature, but a lot of plugins change the way the framework or even the language behaves without much explanation.
Too much magic and syntactic sugar
Don’t get me wrong, I like it when things happen automatically and can be done conveniently. The problem is if they happen automatically some of the time and it’s hard to predict when, or if there’s no obvious way to change it.
This is part of the reason Grails needs way more documentation. It’s nice of them to show me an example of the typical case, but when that example involves Grails magically swooping in and altering what I’ve written, it’s little help in figuring out an atypical case.
Bottom Line
Grails expects you to know what is going on beneath the surface and use that knowledge constantly. It’s a framework optimized for its authors, very focused on providing shorthand ways of doing whatever the authors like to do. Certain things can be done quickly, but there’s not much documentation on how to handle special cases or do things your own way.
