Grails: The good, the bad, the ugly

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.”


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!

25 thoughts on “Grails: The good, the bad, the ugly

  1. 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.

  2. 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.

  3. 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

  4. 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 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.

  5. 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 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”

  6. Pingback: Grails: The good, the bad, the ugly

  7. “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.

  8. 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.

  9. 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.

    • 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.

  10. 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?

  11. 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)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s