10 Common Misconceptions about Grails

Posted by: on Jul 2, 2007 | 12 Comments

As is usually the case with anything "new" there’s a lot of FUD and confusion out there with people who have not used Grails yet, that may be stopping them using it. Here’s a quick list of some of the more common falsehoods being bandied about:

  1. "Grails is just a clone of Rails". Ruby On Rails introduced and unified some great ideas. Grails applies some of them to the Groovy/Java world but adds many features and concepts that don’texist in Ruby, all in a way that makes sense to Groovy/Java programmers.
  2. "Grails is not mature enough for me". The increasing number of live commercial sites is the best answer to that. Its also built on Hibernate, Spring and SiteMesh which are well-established technologies, not to mention the Java JDK which is as old as the hills. Groovy is over three years old.
  3. "Grails uses an interpreted language (Groovy)". Groovy compiles to Java VM bytecode at runtime. It is never, ever, ever interpreted. Period. Never. Did I say never ever? Really.
  4. "Grails needs its own runtime environment". Nope, you produce good old WAR files with "grails war" and deploy on your favourite app container. During development Grails uses the bundled Jetty just so you have zero configuration and dynamic reloading without container restarts.
  5. "My manager won’t let me use Grails because it isn’t Java". Smack him/her upside the head then!** Grails code is approximately 85% Java. It runs on the Java VM. It runs in your existing servlet container. Groovy is the greatest complement to Java, and many times more productive. You can also write POJOs for persistence to databases in Java and include Java src and any JARs you like in a Grails application, including EJBs, Spring beans etc. Any new tech can be a hard sell in a cold grey institution, but there’s rarely a more convincing argument than "Hey Jim, I knocked up our new application prototype in 1hr in my lunch break with Grails – here’s the URL". [** comedy violence kids, not the real kind]
  6. "Grails is only for CRUD applications". Many demos focus on CRUD scaffolding, but that is purely because of the instant gratification factor. Grails is an all purpose web framework.
  7. "Scaffolding needs to be regenerated after every change". Scaffolding is what we call the automatically generated boilerplate controller and view code for CRUD operations. Explicit regeneration is never required unless you are not using dynamic scaffolding. "def scaffold = Classname" is all you need in a controller and Grails will magic everything else and handle reloads during development. You can then, if you want, generate the controller and view code prior to release for full customisation.
  8. "Grails is like other frameworks, ultimately limiting". All Grails applications have a Spring bean context to which you can add absolutely any Java beans you like and access them from your application. Grails also has a sophisticated plugin architecture, and eminently flexible custom taglibs that are a refreshing change from JSP taglib.
  9. "I can’t find Grails programmers". Any Java developer is easily a Grails developer. Plus there are far fewer lines of code in a Grails application than a standard Java web application, so getting up to speed will be much quicker.
  10. "Grails will make you popular with women". Sorry quite the opposite, you will be enjoying coding so much you won’t be chasing any women for a while. We should put this as a warning in the README actually, along with a disclaimer about any potential divorce that might result from hours spent playing with your Grails webapps.

Why not come and hear other people talk non-FUD about how they are building web applications in double quick time at Grails Exchange 2007, tickets available now.


  1. M Easter
    July 3, 2007

    I especially like #5 and #10.

    #5 is very important to understand. I have coined a term “JVM tunneling” — meaning that tools/languages that run on the JVM are sublimely suited to being introduced into an organization. It took me a long time to truly understand the profound consequences of _compiling to bytecode_ and _running on the JVM_.

  2. Stephan Schmidt
    July 3, 2007

    “It is never, ever, ever interpreted. Period. Never.” What about the Byte Code Interpreter? ;-)

    Great post.


    Stephan Schmidt :: stephan@reposita.org
    Reposita Open Source – Monitor your software development
    Blog at http://stephan.reposita.org – No signal. No noise.

  3. Marc Palmer
    July 4, 2007

    Stephan – I don’t get your point? Java is not interpreted. It runs in a VM but that is not the same as interpreting where the source code is parsed directly when executing.

  4. jamesl
    July 4, 2007


    You are right, the java language (and groovy in general use) is not interpreted at the source code level. However, the bytecode that the compile produces is not executed directly by the computer, but indirectly by a program, the Java Virtual Machine. So Stephan is also right, byte code is interpreted.

    Of course it is much faster to interpret byte code than the higher level syntax of Java or Groovy.

    Rgs, James.

  5. Marc Palmer
    July 5, 2007

    Indeed, it is NOT interpreted like Ruby or other scripting languages. :)

  6. Nando
    July 12, 2007

    Great points. I must say that I’m very happy with Grails so far, I created a Grails application that is now running in my company intranet. It works really well and development is fun. I looked into RoR at first, but I didn’t want to learn Ruby, so doing a little more research found about Grails… it was a no brainer for a Java developer like me!!!

  7. Yuri
    July 15, 2007

    Grails is a great framework! I have been playing with it for the last several weeks and I must say that I like every side of it, apart from using Groovy as the scripting language. The idea to use a Java syntax language is great, but for me Groovy has been a disappointment so far. May be Nice would have been a better choice. Groovy has many good features, but it is a mess of a language and its performance sucks.

    About point 3 – the benchmarks I’ve seen put Groovy as the slowest JVM language, so from users’ point of view it is as good as interpreted regardless of whether it compiles to byte code or not.

    A misconception that should be added with respect to Groovy is: “Groovy compiles to static invocation byte code, especially in the cases when it makes all the sense to.” I must say that I fell for that misconception from the description on Groovy’s website.

  8. Marc Palmer
    July 17, 2007

    Yrui – Groovy is the perfect language for Grails, and in fact Grails almost certainly could not exist with out it. As has been mentioned before it -might- be possible to use Ruby with Grails, but even that may be tricky.

    Grails is based on the notion of completely dynamic languages, and as such Groovy’s dynamic typing, builders (DSLs) and closures are a vital part.

    What’s more, it is vital that it is as close to Java as possible in syntax. This smoothes the migration path.

    Performance is and will continue to improve.

  9. Russel Winder
    July 17, 2007

    10 implies that there can be no heterosexual women Grails developers?

    Aren’t there laws against that sort of discrimination? ;-)

  10. Marc Palmer
    July 19, 2007

    Well women will get as much pleasure from Grails as men, perhaps more. I fully expect spam email along these lines soon, it is only a matter of time.

  11. Marc Palmer » Blog Archive » My JAX London 2010 talk now online in video form
    March 1, 2010

    [...] People interested in making the case for Grails may be interested in an older post of mine that I’d completely forgotten about – “10 common misconceptions about Grails”. [...]

  12. Steve
    March 8, 2010

    Never forget: grails install-templates
    Live in scaffolding as long as possible! :)