Why aren’t you using Grails at work?

Posted by: on Dec 14, 2009 | 14 Comments

As mentioned earlier today, I’m going to be talking at JAX London 2010 about how you CAN use Grails.

I would like to hear however, the reasons why some of you may not have been able to use Grails at your place of work. I’m sure there are many amusing and probably frustrating stories.

OK, I’m looking for soundbites for the talk. Come on, feed me!


  1. Steve
    December 14, 2009


    Up until recently I was a consultant in the JEE space and use Grails on personal/side projects. When I would pitch Grails to IT Teams I was working with, they almost all said, “Not Another Language”. As much as I could I would focus on how similar Groovy and Java are and that Groovy is easier IMO. The one thing though that got ooh’s and aaah’s was a demo. Showing them how fast I could get an app up and running was the key to getting them hooked.

  2. Erik Pragt
    December 14, 2009

    Hi Mark, excellent question!

    Is this something like the answer you’re looking for?



  3. Sébastien Blanc
    December 14, 2009

    Hey, not really enough stuff to tell about my own experience but Erik Pragt just wrote an excellent blog post about this subject : http://dontmindthelanguage.wordpress.com/2009/12/14/why-im-not-using-groovy-at-work/

  4. Jan Sokol
    December 14, 2009

    Recently I switched job and as I am in the position of decision maker I pushed Grails (although team was more for Wicket). I didn’t regret this decision but there are some frustrating points right away from the beginning.

    Probably I will write some blog posts but here is some short list that was quite frustrating for us:
    - build process: we decided for ant/ivy. But when you create grails project and try to build it with ant it fails. After some browsing you find solution on Internet
    - for some reason running and testing application using ant is much slower than using grails from command line. So we are very often using grails run-app/test-app instead of ant run/test
    - local plugin repository. Publishing internal plugins does not work after first release of the plugin. We had to introduce our own script for this
    - when you are developing with internal plugins upgrading version of plugin on Hudson is two steps process. First build uninstall plugin and fails, second build that must be started manually on Hudson installs plugin and success. The situation is same for developers when they update project from the SVN.
    - and what is mentioned on http://dontmindthelanguage.wordpress.com/2009/12/14/why-im-not-using-groovy-at-work/ some people just don’t want to get into Grails (but this obviously is not problem of the grails)
    - IDE support is bad. I would say it would be almost impossible to work in team of 5 if we didn’t buy InteliJ

    More or less there were/are some problems when starting with project but I am still very sure that we are going forward faster than we would with some other web framework.

  5. Raffaele
    December 14, 2009

    Vendor lock: Coldfusion everywhere.

  6. Richard Spence
    December 14, 2009

    I know I am hardly a corporate but I figured these thoughts could help in you talk:

    My angle is that I am using grails for work but I am shy of using it for core apps as

    1. I am concerned that I cannot get external people to help as grails skills are rare.
    2. Worried that the grails dev bods are a small team and that I could be left high and dry if grails is not popular.

    So although using grails is used in small tactical apps at the mo.

  7. hbagchi
    December 15, 2009

    We have just started work on a new application using Grails. It is indeed a fantastic web framework and delivers high developer productivity. However, there are some key initial obstacles IMO I noticed, to begin with, to greater Grails adoption:
    1. IDE – Using free Eclipse over the years have got the developers hooked and it always comes as a shock to most to abandon it and use a text editor if you can’t afford IDEA. STS 2.2.1 is not a comparable IDE.
    2. Developer Mindset – Configuring XMLs (navigation, security, beans etc) in J2EE applications has got so ingrained in the developer mindset that explaining them the Grails way of “Convention over Configuration” takes time and effort. The unlearning involved is significant.

  8. Eelco Hillenius
    December 15, 2009

    I’ve been one of the early (pre 1.0) adaptors of Groovy, and back then the language utterly failed in my project. I had to swap it out for another scripting implementation because of stability and very serious performance issues. Looking at the implementation and seeing some of the inconsistencies after that made it clear to me that the initial design of Groovy was deeply flawed, and unfair to the current version and it’s maintainer as that may be, I’m still left with a gut feeling that Groovy is a language with a shaky foundation.

    I have no strong feeling about Grails other than that it is based on Groovy and that I personally prefer frameworks that try to leverage static typing, like Guice, GWT and Wicket do (funny btw that some people think that because there are loopholes in that static support, you might as well throw everything out).

  9. Eelco Hillenius
    December 15, 2009

    @Jan Sokol

    Really, your team favored framework A and you forced them to use framework B? That’s pretty awful. I mean, yes if your team favored EJB 2 over Hibernate or Struts over Grails you would have a point, but with Grails vs Wicket (vs GWT vs Flex vs Ajax directly vs…) you definitively get into a grey area. I’m biased being a Wicket developer, but I highly doubt you will be (that much if any) efficient developing with Grails instead of Wicket, especially if your team was already experienced with the latter.

  10. Benoit Leprevost
    December 15, 2009

    In my case, I struggled to convince my bosses/collegues because they were scared to invest a quite big amount of resource/time in a language/framework which had not really taking off. Some people still prefer to wait and see how that “next generation of language on the JVM” battle is going to unfold.

    What’s true, as the quoted blog mentioned, is there’s quite a lot to learn, and to tweak in order to have it smoothly running in your company like the java projects are doing.

    I suspect some aspect get overlook by people working on “pet project” mode like:
    - JAAS/J2EE security integration (I know it’s crap but …)
    - local plugin repository: I had issue because my local SVN is local, not accessible through firewall, but the firewall was needed for the “default” repo

    What I would like is a few AppFuse/maven artifact kind of bundles. Each of them should be targeted at one of the typical usuage of Grails: pet project, cloud, startup, J2EE corporate, etc … They would come with plugins preinstalled, modified scafoling and user guide. Maybe they could be just master plugins …

    I don’t know, just my 2 cents

  11. Antoine
    December 16, 2009

    Well, if I read you, this is because I am Grails user, so not exactly the kind of feedback you are looking for ;o)

    Anyway, one year ago, I had to choose a Java framework. I quickly saw good feedback on Grails, but at first, I did not want to use it : that would mean for my team to learn another language I did not want to loose time with this.
    Being not entirely satisfied with what I tried, I finally came to try Grails. This trial made my heart sink, and now we are using Grails at work :o ) I was seduced by how easy it was, how quickly you could set up an application and the fact that all the frameworks used are already bundled, without the need to spend time configuring each one to work with others.

    When I present Grails to others (even students), they often enquire about IDE support: not having auto-completion in Java world is nearly a blocking point. But IDE support is getting better now.

  12. Mike Miller
    December 16, 2009

    Interesting because I’ve been looking at Groovy/Grails for about a year now. I am trying to slowly ‘sneak’ it in whereever possible. I started with a quick web app to help test a RESTful web service we added. As the occasions arise, I also try to develop helpful scripts in Groovy.

    Part of feedback/concern from other developers is “If we aren’t going to get to use it regularly, then I don’t want to spend the time learning it right now”. The other resistance is just plain apathy.

  13. Marc Palmer
    December 17, 2009

    Ah yes, and that’s the irony. Groovy is so easy for Java devs to learn. Its easy to switch and then evolve their proficiency over time.

  14. Jan Sokol
    December 12, 2010

    One year later we have developed and deployed three relatively big web based projects (most of which is developed in Grails). Team is more than happy with Grails and they are even doing “home pet” projects with Grails.

    I believe our decision was correct and now most of our development is done with Grails.