After 3 years of Grails development it is time to take a step back and look how well we went.
(Info: we made several Grails apps ranging from small (<15 domain classes) to medium sized (50-70 domain classes) using front ends like Flex/Flash and AJAX)
The good parts
Always start with praise. So I tell you what in my opinion was and is good about developing in Groovy and Grails.
Groovy is Java with sugar
The Groovy syntax and the type system are so close to Java, so that when you come from a Java background you feel right at home.
Standard web stack
If you are accustomed to standard technologies like Spring and Hibernate you see Grails as a vacation.
Sensible defaults aka Convention over configuration
Many of the configuration options are filled with sensible defaults.
Fast start
You get from 0 to 100 in almost no time.
The bad things
Things which are not easily avoided.
Bugs, bugs, bugs
Grails has many, many bugs, unfortunately even in such fundamental things such as data binding and validation. A comment from a previous blog post: “To me, developing with Grails always felt like walking on eggs.”
Regression
Some bugs sneak back in again or are even reopened. Note that this is not the same as bugs, bugs, bugs because fixed bugs should be secured by a test.
Leaky abstractions
You have to know the underlying technologies especially Hibernate and Spring to get a foot on the ground. The GORM layer inherits all the complexity from Hibernate.
Slow integration tests
The ramp up time is 45 s on a decent build/development machine and then the first test hasn’t even started.
Uses the Java way of solving problems
Got a problem? There’s a framework for that!
Abandoned or prototype like plugins
Take a look at the list of plugins like Autobase, Flex.
Problems with incremental compiling
Don’t know where the real cause is buried: but using IntelliJ for developing Grails projects results in comments like:
Not working? Have you cleaned, invalidated your caches, rebuilt your project, deleted the .grails directory?
The ugly things
Things which are easily avoided or just a minor issue.
Groovys use of == and equals
Inherited from Java and made even worse: compare two numbers or a String and a GString
Groovys definition for the boolean truth
0, [], “”, null, false are all false
Groovys use of the NullObject and the plus operator
Puzzler: what is null + null ?
Uses unsupported/discontinued technologies
Hibernates SchemaExport comes to mind.
Mix of technology and intention
hasMany, hasOne, belongsTo have not only an intention revealing function but also determine how cascading works and the schema is generated.
Summary, opinionated
Grails has deficits and is bug ridden. But this will be better in the future (hopefully).
When you compare Grails with standard web stacks in the Java world you can gain a lot from it.
So if you want to know if you should use Grails in your next project ask yourself:
- do you have or want to use Spring and Hibernate?
- can you live without static typing? (remember: with freedom comes responsibility)
- are you ready to work around or even fix an issue or bug?
- is Java your home?
If you can answer all those questions with Yes, then Grails is for you. But beware: no silver bullets!
Schneide Blog 
I concur with most of your ugly list. But I believe that the boolean truth point is a strength of groovy. I think the caveat of “with flexibility comes responsibility” applies to this feature as well. Groovy will allow you to be more specific if you want, both with the truth conditions and static typing.
Yes, you can avoid the Groovy truth and make it explicit (therefore it is filed under ugly). But you cannot use all benefits of static typing (see https://schneide.wordpress.com/2010/12/27/groovy-isnt-a-superset-of-java/ for an example).
I found particularly the integer boolean truth troublesome: an int with value 0 is not really false for me and I think there are a lot of pitfalls in the definition and usage of the boolean truth.
Very interesting article based on a lot of experience with Grails.
However, after using Grails myself for projects one of the major plus points that you have left out is its plug in system. True some of the plug ins are abandoned as one would only expect from code that relies on the community but others are well implemented and simple to add to your project.
It is also true that you have to be very very careful with a dynamic language as the compiler will not be there to catch problems but this just means that it is more important than ever to write unit and integration tests for the system. (This should not increase the amount of time it takes to write an application because of course these would be written for web apps written with other frameworks, right? :-))
Additionally, regarding your comment about how it takes 45 seconds to ramp up your integration tests, I have never had this problem unless you are including the time it is taking for the system to compile and run the app.
Well we use migrations via Autobase/Liquibase which additionally slow down the startup, so 45s might not be accurate as the ‘vanilla’ ramp up time.
I agree with you that you should write more unit and integration tests which we do. But I also see that programmers coming from a static typed language like Java tend to be more ‘lazy’ when using Groovy and want to really feel the freedom.
I think the plug in infrastructure is like in many other open source communities, there are many plug ins, some are great, some are decent and some are abandoned. In our experience though we found that some or most of the plug ins we use are a great first take but were abandoned. This hurts when you have a long running project but can be neglected in short ones.
The plug in system itself is okay but inherits some Java classpath problems.
Yep… you nailed all the ugly for sure… After 3 month of grails i moved back to Std spring/hibernate.
Use the Play! framework (http://playframework.org) instead! =)
One thing on the plus side that you didn’t mention: it fits very well with shops that use Java.
Other reasons to use Grails:
* Your admins know Tomcat or other Java Web server
* Your shop uses existing Java libraries and you need to integrate with them
* Your shop has existing code that you need to integrate with
Let me add the pain to externalize configurations such as log4j to the ugly list. If you don’t want to stick to the configuration it is quite hard to get Grails to acknowledge simple log4j.properties on the classpath.
Good point!
With log4j we went so far as to use a log4j.xml for production use (inside the templates) and the Config.groovy for development and test purposes.
I think play! framework (http://playframework.org) deals nicely with many of the problems listed here, although it still lacks grails maturity and rich plug-in ecosystem, which is growing fast BTW…
The abstractions do leak, but it’s very difficult to avoid that. Nonetheless, Grails does simplify much of Hibernate, Spring, and other libraries. But for serious work, you do eventually need to know about what’s happening under the hood.
I’m interested in what you mean by “[Grails] uses the Java way of solving problems”. What exactly is the Java way and what are the other ways you’re thinking of?
The plugin portal is slowly improving and we will continue to add more information to it.
Interestingly, the ugly Groovy bits you cite are big improvements over Java in terms of usability to my mind. There are ugly bits, particularly with comparing Strings and GStrings, that come from the language being tied so closely to the Java platform (CharSequence was unfortunately introduced too late so we’re left with a slightly broken API).
I don’t think it’s surprising that Grails doesn’t keep right up to date with the latest versions of everything. Do you often find this an issue? On SchemaExport, I think you’ll find the new Database Migration plugin a suitable replacement.
On the technology/intention front: could you expand on what you think the issue is with hasMany/belongsTo/hasOne influencing schema generation and cascading? When I first started with Grails, these conventions helped me get apps up and running quickly without first having to learn SQL and how to set up foreign keys, cascading, etc. Perhaps it’s because I’m getting old, but I prefer technology that takes my intentions and does whatever is necessary to make things work. I would agree that there are situations where things don’t go entirely smoothly, but I disagree that the fundamental approach of intention influencing DB configuration is wrong.
BTW, the above are genuine questions of enquiry. I’m always interested in getting user feedback about Grails.
Hi Peter
first thank you for your continuing effort in developing Grails!
“[Grails] uses the Java way of solving problems”
I understand that one main design goal of Groovy is compatibility with Java. But I wish there would be more dynamic features leveraging the power of dynamic typing and meta programming. I see the rich ecosystem of Java is a great help but some decisions and frameworks/libraries need to be rethought or redesigned. Java has its constraints and I think a language like Groovy and all the other new languages on the JVM have a big opportunity to make new ground here and be free from relics of the Java world.
“the ugly Groovy bits”
I think NullObject.plus() is a pitfall. Also the difference and sometimes the similarity of equals and == is confusing.
“the latest versions of everything”
I think there is a thin line between innovation and stability and it is not easy to choose either side. Also the other line is between getting a quick start and having a good solution in the long term. I think Grails excels in the first point. Migrations are necessary for longer running projects but I see you get a head start with schema generation.
I would like to see more improvements in areas like security (XSS and XSRF). I know the global configuration option for escaping but I found it colliding with some of the tag libs.
“technology/intention front”
Well maybe I am old school here but having learned SQL and all the database specific stuff you have to deal with, I personally prefer thinking in database tables and foreign keys. And I always have to look into the documentation and the examples to remember what each hasOne/belongsTo/hasMany does and which implications it has.
“I’m always interested in getting user feedback about Grails”
Great!
“You have to know the underlying technologies especially Hibernate and Spring to get a foot on the ground. The GORM layer inherits all the complexity from Hibernate.” – I disagree with this regarding Spring. I’ve never used spring for anything ever and had no problem with Grails. What type of work were you doing where non-basic knowledge of the spring framework became necessary?
Well, we had to create our own Spring configuration with custom beans, used Spring AOP and webflow. If you understand dependency injection and inversion of control, I think Spring injection is trivial. Webflow needed some planning and has some implications (like Serializable) for your code which are not obvious at first sight.
I’m using Grails since 2008 and previously I’ve been developing web applications using some well established web frameworks like JSF and JSP, hibernate, spring, ibatis – you name it. In my opinion it is vital to understand that whenever one is faced with simplified usage of currently existing technologies one also must accept the fact that there are going to be some things that are easier to achieve and some that will be hidden behind layers of abstractions.
As far as I am concern all technologies have their respective uglinesses. JSF for example is a major pain in the neck when it comes to creating custom components and the quality of the existing ones is far from being even acceptable (take a look a RichFaces and their code base to know what I’m talking about).
In all it’s simplicity Grails is just a couple of layers on top of well established libraries binding them together in a foreseeable mass that can be worked with. Even if there are bugs and sometimes I feel like I’m gonna kill the programmers who did that thing I’m most pleased with the actual outcome.
When it comes to the dynamic nature of Groovy and its “ugly” stuff like comparing strings… Well, write unit tests, get some nice coverage and then you’ll know what your code actually does. Without unit tests (regardless of the language being used) it is a mind field you walk.
How stable (non-buggy) is Grails in 1.3.7? I.e. are most of the problems you had with older releases?
Grails 1.3.7 is stable. Most of the problems have been fixed. But beware when upgrading from a version pre 1.3 since they changed a lot of the details.
See also https://schneide.wordpress.com/2011/03/14/grails-upgrade-lessons-learned/
As for the equality versus == in Groovy and Java:
My believe is that this is ugly in Java and not in groovy. Groovy just returned to the good old interpretation of the == sign that appeared in many languages and made the learning curve of Java just a bit more difficult.
At some time in the past some person could have decided to use == instead of equal() and use something like ‘same()’ instead of ‘==’. This train has gone long time ago and there is no reason to cry over the spilt milk (could have been beer being spilt after all).
Was it a good decision for Groovy to return to the original track? Probably not. Imho. After that mistake of Java Groovy can not amend it.
What you recommend for a newcomer to java web framework, familiar with php and java development?
I personally can’t recommend a newcomer framework. It depends on the type of project you want to tackle. Most frameworks which give you a fast start neglect the structure or architecture of your application and this will hurt you faster than you want to. The frameworks which give you a architecture have a steeper learning curve because you need to learn the concepts of the platform.
Groovy use of == and equals. Replace x == y with x?.equals(y) – see O Reiily book: Programming Grails – Burt Beckwith =- P18.
but what about 1.0 == 1 and (1.0).equals(1) ?
Why is Groovy’s == modelled more after equals in Java but not in all cases?
I strongly agree …. I developed applications on the very early applications of Grails and they were very good … Now after more than 3 years of absense, I find it very difficult and slow to develope in Grails 3.
Because, many things won’t work as expected due to bug. But if Grails was without bugs, this would be the best ever framework for web programming of all time.
In the meantime I prefer JRuby on Rails to Grails: no hibernate, better view templating and many, many libraries (gems) which make common tasks much easier than in Grails (e.g. authentication)
Did Java for 14 years, Node for 2 years, and now Grails for 3 months. Grails is the worst of all worlds. All the hoops of Java, without the type-safety net. I’ve got a Node project going along side several Grails projects. The Node project is going about 10x the speed and quality
We are doing Rails on JRuby nowadays and it is so much better than Grails.