Usually, I try to avoid it but this time a Disclaimer is in order: This is not a Grails rant. Most of the time developing Grails projects is fast and smooth. Using Grails brought many advantages for us. But there are also dark sides…
My main criticism is that Grails abstractions are more than leaky! In every list of examples for the definition of the term Leaky Abstraction Grails should be top. As soon as you leave the tutorial/scaffolding/helloworld level you have to know a lot about the underlying stack. And with Hibernate and Spring neither of the words small, easy and lightweight do apply.
GORM, too, is only easy to use at first sight. The very informative blog series about GORM gotchas should absolutely become part of the user guide or the refence docs.
And there are those times where it gets really unpleasant. This is e.g. when a bug does appear in your grails application running in a servlet container (packaged in a .war)Â but does not appear when the application is started from within the IDE. Our last one of those was a naming conflict in a .gsp file. The controller handed a model like this to the .gsp:
... return [fieldValue: 'THE_VALUE', ...]
The model entry ‘fieldValue’ was used in the .gsp to set the value of a combo box. Unfortunately, ‘fieldValue’ is also the name of a built-in Grails tag …
Admittedly, ‘fieldValue’ was not the wisest choice of names and I would certainly expect to get scolded loudly by Grails for that – ideally with a nice descriptive exception. But what happend instead led to a loud scolding of Grails from us. And to some big question marks: What is the difference between executing Grails from the IDE and within a servlet container with respect to naming resolution? Why is there a difference, at all?
We had a hard time figuring out this one, not least because the error message was not very telling. And since this was not the first of those works-in-the-IDE-but-not-in-a-real-environment bugs there is always this slightly uneasy feeling…
As I said in the beginning, most of the time developing Grails applications is nice and shiny. I would not support their slogan, though. My personal search for the best web development tool is definitively not over.
How about your search?
Schneide Blog 
Good point, but would you rather go back to Struts?
Mine is… it’s called Ruby on Rails. 🙂
My search is over since I switched from Grails to Play. To me, developing with Grails always felt like walkin on eggs. As a result, my project only took small step. Since switching to Play, things started to move a lot faster.
Grails in my mind inherits too much baggage while trying to masquerade it under a pretty umbrella. Play is more opinionated and just throws away what it does not like (e.g. Servlets). But nearly everytime the decisions are good and enable a very nice development experience. More time can be contributed to making your app more awesome instead of figuring out which of the hundreds Grails JIRA entries is currently affecting you.
I share the same view with the author. Most of the time Grails runs just fine, but for sometimes I have to deal with some *weird* issues, and then I have to start searching for solutions/workarounds (although Grails motto is ‘The search is over’, kinda funny). I think the Grails dev team should spend more time on documenting all the corner cases/quirks. It will help other people saving their time from searching over and over again for workarounds.
Anyway, it’s just my two cents!
For me grails is doing a website using spring/hibernate/ etc whilst holding a magic wand that does all the plumbing for me.
I already know Spring and Hibernate inside out so it gives me a massive leap in productivity. But i can imagine that if you where trying to take short cuts by not understanding the underline frameworks it sits on then you would at some point you would get confused trying to to something complex.
I have worked with Spring and Hibernate and in my view, its overly complicated. Its just that you really feel good by having lots of configuration files that you are really doing something cutting edge.
I like the Groovy language very much but one thing I cant help noticing is that its too much bloated having too much features. But nonetheless, its a really nice language.
But when it comes to Grails, It copies the Rails but that too in a bad way by sitting on top of Spring and Hibernate and adding another lets named Groovlets. That’s real stupid.
Having worked with Rails and Spring, I do not think that spring is something to be used at all. Play framework is great and so is scooter.