Unfavorable Grails Review Response

After being away from the Grails mail lists for the past few weeks, I came across a thread that discusses an unfavorable review of Grails on ohloh.net.

The reviewer has five qualms with the framework... which probably leads to the 1/5 rating. Over the past few months I've deployed four Grails applications to production. I'd like to use my experience to discuss the user's qualms.

"1. The biggest problem is definitely the lack of support for advanced features, specially in queries. If you want to do any kind of advanced querying then you will be writing SQL code. The framework simplifies SQL to an ... [More] unrealistic point. If you are using associations (something so basic) then good luck doing any kind of advanced filtering, sorting, etc... with the built in tools."

I'm not sure this one is even worth arguing. This qualm is against Hibernate - not Grails. The arguments FOR Hibernate have been made countless times... and that horse has been beaten to death.

"2. Debugging is a mess. If you have an error during your bootstrap or other start up problems then good luck if you can even read the stacktrace in your command prompt (They have over 500 calls in the stacktrace). I had to pipe mine out to a file then read the file in notepad.

If your bug is in your controller/view then you get a nice webpage with the exception. The only problem is that the error message on the website is 95% not your actual problem. It will tell you the problem is on line 150 while the problem is most likely down another 50 lines."

I would agree in part with this point... Groovy stacktraces can be tough to make sense of. Grails has helped the issue a bit by introducing a stack sanitizer in the GrailsUtil class. This is a class that is employed by framework code, and typically won't be leveraged by Joe-Developer.

Addressing this point in full would require asking the developer on how they employ TDD in their development environment. Without writing tests first (yes, even with BootStraps), coding in a dynamic language can be EXTREMELY painful.

"3. The documentation is poor. I used Grails to do a semi-advanced project and outside of the basics, the documentation will not get you far. I found myself often searching on google for answers and through trial and error."

IMHO, the user guide is pretty good, but overall the documentation is pretty weak. In fact, I would go as far as to say the Grails website is an embarrassment. Ever since G2One 'ate their own dog food' and powered the Grails website using Grails, it's been a bit chaotic.

As development shops continue to explore Grails, there will likely be many developers who urge the 'powers that be' to take a look at Grails. What a shame it would be for upper management to disregard the power of Grails (and the paradigm shift towards convention, for that matter) because the Grails website isn't readable.

Over the past few months - things have gotten better. Some Good Samaritans in the Grails community have taken it upon themselves to clean up some of the formatting on Grails.org. I hope this continues to improve.

"4. Memory consumption and performance. Grails is a memory hog. My website when doing absolutely nothing consumes nearly 80 megs. One of the main problems that may increase your memory consumption and/or CPU is because of problem #1 on this list. You will so often be doing advanced things manually that should be done by the database and/or the framework. Many times I had to duplicate/triplicate objects to accomplish what I needed."

... not sure how to answer this one either. It's tough to comment without knowing what the user has to work with. What are their JVM settings, etc?

Without a sound understanding of the underpinnings of Hibernate - things can get painful. Memory can be an issue.

In my experience, Grails memory consumption hasn't been as bad as I've seen reported. I've deployed production Grails applications to both Windows and *nix JVMs. Oh - and two of the four applications I've deployed use the Quartz plugin. For those unfamiliar with the plugin - it's essentially user managed threads that execute on a timed fashion.

"5. Buggy. The framework randomly throws Hibernate errors (concurrent session problems etc..) when I am browsing my website. You refresh the page and the problem goes away."

What errors? Randomly? Again, a sound understanding of Hibernate is required to be really effective with Grails. 'Random' errors can occur with Hibernate if you have an application that does A LOT of concurrent updates. If that is the case, the user is likely seeing Optimistic Locking Exceptions. This is not 'random' and is, in fact, a feature of Hibernate. More on optimistic / pessimistic locking can be seen in the Grails documentation.

Outside of the Hibernate stuff, I have encountered a few bugs. No show-stoppers though. Here's one I found related to 404 mappings and another related to declarative 500 error code processing.

Finally, the poster suggests that Grails is not ready for 'real world' scenarios. I disagree... as do these folks.