Comments on: Why aren’t you using Grails at work?

By: Marc Palmer

Marc Palmer — Thu, 17 Dec 2009 12:31:26 +0000

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.

By: Mike Miller

Mike Miller — Wed, 16 Dec 2009 18:29:31 +0000

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.

By: Antoine

Antoine — Wed, 16 Dec 2009 07:57:44 +0000

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

By: Benoit Leprevost

Benoit Leprevost — Tue, 15 Dec 2009 10:15:08 +0000

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

By: Eelco Hillenius

Eelco Hillenius — Tue, 15 Dec 2009 06:30:49 +0000

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

By: Eelco Hillenius

Eelco Hillenius — Tue, 15 Dec 2009 06:26:30 +0000

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

By: hbagchi

hbagchi — Tue, 15 Dec 2009 01:48:09 +0000

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.

By: Richard Spence

Richard Spence — Mon, 14 Dec 2009 22:21:23 +0000

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.

By: Raffaele

Raffaele — Mon, 14 Dec 2009 22:16:41 +0000

Vendor lock: Coldfusion everywhere.

By: Jan Sokol

Jan Sokol — Mon, 14 Dec 2009 21:40:02 +0000

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.