Grails Misconceptions

| by Geoffrey Wiseman Follow 0 Followers on Jul 11, 2007. Estimated reading time: 2 minutes |

Marc Palmer, a Grails committer, posted about some of the common misconceptions that developers have about Grails, such as "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.

And, in response to "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.

Finally, talking about whether or not 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't exist in Ruby, all in a way that makes sense to Groovy/Java programmers.

Graeme Rocher followed up with his own list of misconceptions and questions, such as "Who needs Grails when we have JRuby on Rails?":

This is a classic and is the foundations for one of the biggest misconceptions about what Grails is. JRuby on Rails is an excellent way to run Rails apps on a Java EE container like GlassFish. End of story. Grails has very different goals. It is not a port of Rails to the Groovy language. It is the act of bringing together solid industrial strength components like Spring, Hibernate, Quartz, Compass, Sitemesh etc. and making them DRY by embracing convention-over-configuration.

We're not re-inventing the wheel and because the vast majority of the core of Grails is Java it is more robust and performant. Grails is actually a Spring MVC application at its core and is deployable onto all major containers, not just Glassfish, including the big commercial ones such as WebLogic, WebSphere and Oracle AS.

And, "Why is Grails more suitable than Rails for the enterprise?"

A number of reasons. Two of the biggest ones are Spring & Hibernate. As it stands to day a enormous number of organisations are using Spring & Hibernate. They have existing Spring context, existing Hibernate domain models, and so on.

I was in this same situation before I started working in Grails. Grails is designed to integrate with these frameworks as seamlessly as possible. So for example you can drop a Hibernate domain model written in Java and mapping files into a Grails app and start using dynamic finders and GORM straight away.

In addition Grails controllers use standard Servlet API objects like request, response, session etc. and can sit alongside other servlets. It is after all just a Spring MVC application under the covers. Rails on the other hand is designed almost in a way EJB2 was designed (shock, horror bear with me while I qualify this). In other words you extend framework objects like ActiveController, ActiveRecord etc. which bind you to the framework.

There is also no such thing as a domain model in Rails. Rails models are database tables. This is all well and good, but in enterprises the same domain model is often re-used in multiple applications both desktop and web. This is effectively accomplished in Java by packaging the classes with the mapping files in a JAR.

Do you have other questions about Grails, or have you seen other misconceptions about its use? Share them with us here, on InfoQ's Java community.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Maybe they should have chosen a different name by Brian Dittmer

If it's not a direct port of Rails and only borrows some concepts from Rails maybe they shouldn't have started out with the name Groovy on Rails and when they did decide to change it maybe they should have picked something totally different. The misconceptions problem would probably be a non-issue then. (Disclaimer: I'm a huge Grails fan)

Re: Maybe they should have chosen a different name by Mirko Nasato

Similar considerations for "Grails is not mature enough for me": the current stable version is labeled 0.5.6. Most people will probably wait for the 1.0 release before considering it "mature enough".

Re: Maybe they should have chosen a different name by Graeme Rocher

I certainly agree with both of your points, unfortunately changing the name now would be tough going.

As for 1.0, we're working towards a release later this year, but your point certainly stands. Once the 1.0 release is out I hope more people will consider Grails as an options.

Grails vs Rails by Sergei Rogovskiy

Few things to point out:
a) why is it so slow if it is complied java bytecode. (6 req/sec on high-end g5)
b) one of the main ideas on Rails is no XML. This was totally ignored by Grails as far as I can see which makes it another java thing where java and xml are randomly mixed up.
c) generate model takes forever - development tools are slow

To conclude: a) - c) makes development slow which is directly opposite from what you can see in Rails.

P.S. I am a java guy btw

Re: Grails vs Rails by Graeme Rocher

a) Not sure where you get this 6 req/sec figure from, maybe you were benchmarking against development mode. As Marc's blog said use "grails war" create a war ready for production. There are benchmarks on the grails site showing grails processing over 100 req/sec
b) What XML? You can write an entire grails application without touching a line of XML. Sure we allow access to the Spring XML if you want it, but its not a required activity
c) Yes we're working on improving this, but its a once off activity. I'm not generating scaffolding code all the time personally.


Re: Grails vs Rails by Geoffrey Wiseman

I'm interested to see more REST support in Grails, I gather it's entirely possible to do, just not 'incredibly easy' to do (see RoR 1.2's REST support e.g. resource_scaffold). Am I misconceiving how easy it is to do now? I wasn't able to track down a quick five-minute "how to do REST in Grails" post anywhere, so if it's really easy to do, perhaps someone should write up a quick blog entry on the subject?

Re: Maybe they should have chosen a different name by Sebastien Auvray

Fact is with a different name, Grails wouldn't have raised that much interest as it did.

Re: Grails vs Rails by Sergei Rogovskiy

I feel like I have to correct my self. Really in production it is about 40r/s

ab -n 1200 -c 30 "http://localhost:8080/test-0.1/book/list"
Requests per second: 43.49 [#/sec] (mean)

Which isn't great I'd say, still not six.


grails generate-all Test 41.66s user 152.06s system 99% cpu 3:15.63 total

I really hope that something is wrong with my machine... cause it doesn't have to take over 3 minutes to generate 5k of code.

Anyways, I think the big thing for rails is development cost cut which is not entirely possible with grails at least right now.

I think it doesn't really make sense to make comparison right now. Neat idea, but need to work on implementation ....

Re: Grails vs Rails by Graeme Rocher

grails generate-all completes in 42s on my MacBook 1.83ghz, but yes we need to improve on this.

As for the performance, we're aiming to improve this, but as the benchmarks show, we're still faster than Rails:

Currently our bottleneck is the view tech, GSP which takes about 80% of the request processing time.

So although yes we need to improve, and work to optimise (a part of the dev cycle we haven't reached yet) we're not the only implementation that needs work ;-)

Re: Grails vs Rails by Graeme Rocher

And btw if you are basing the speed of development on the speed of generate-all and scaffolding then you must be developing pretty boring apps or not using the frameworks as intended.

Grails and Rails are for far more than just CRUD, and most experienced Grails/Rails users tell you, you start off using scaffolding as a learning tool, but quickly abandon it and just use the framework itself.

Makes me love Java by Thom Nichols

The seamless integration with Java is such a huge win in my book. If I was going to create my own website I might not use Grails since hosting a Java webapp is not the easiest...

But for enterprise development on the Java platform, it's hard to beat :) Stability is great too. Even the snapshot builds are fairly stable and backwards-compatible.

Re: Grails vs Rails by Marius Vasilache

What is the percent in Spring with JSP ? 80% seems quite high.

Re: Grails vs Rails by Graeme Rocher

80% is high, that is why we know it us our bottleneck ;-)
Obviously it depends in the GSP view (simple or complex) but we need to work on the parser and improve it then Grails will be blazing fast.


Re: Grails vs Rails by Nicolas Doye

Having already deployed an Ajax, CRUD, Grails app on at work, I can tell you that:

  • If I'd used Perl, PHP or a Java framework, it wouldn't be finished, and would probably not contain the Ajax part.

  • If I'd used RoR, I'd still be learning Ruby :-) Groovy is so Java-like (plus I get to call Java stuff I already know) and GSP so JSP-like, it's a piece of cake to learn.

  • It's fast enough - sure it's slower than Servlet + JSP - but in the real world of sites that aren't receiving 500,000 page-impressions per day - who cares? Job done.

I'd say that (J)RoR and Grails both have a great future. They both meet a need and have sweet spots (like Perl and PHP both have done and still do).

PS. I didn't write any XML for my application. Schweet.

Re: Makes me love Java by Jez Nicholson

Another big plus for me is that I can plug in code that works with Spring, so the Grails platform can be expanded fairly easily to use loads of other libraries.

Definitive Guide to Grails by Roger Studner

My favorite part.. is they release a book.. that was for versino 0.3 of grails.

Note.. you coudln't use the book with 0.3

Or 0.3.1
Or 0.4
Especially not with 0.5

I've posted errata on the apress website.... no response.

I've attempted emailing authors... no response.

They should just take the book off etc.. You can't get to page 65 in it, with any version of grails :)

Re: Definitive Guide to Grails by Graeme Rocher

I'm the author and Grails all the way up to version 0.5.6 is backwards compatible. We have only made one change in 0.5.6 that is not and its in the releasen notes.

I've had no e-mail from you personally, but we have a very enthusiastic mailing list, where you can post your problem and we'll help out.

Productivityx3 by Nacho Brito

We are a spanish software development company (ImaginaWorks Software Factory:, our core business is to develop custom software for other companies, mostly web-based. We adopted Grails as our main development platform in April, and all I can say is that our productivity has multiplied by 2 or 3. Once we got used to Grails way of manage artifacts and applications, we are able to create a prototype in 10 minutes, and update existing sites much more quickly.
And we've touched no xml config file since then, all of our configs are groovy files :-)

It's true that the framework is a bit unstable at this moment, some migrations (specially 0.4.2 -> 0.5) are a bit scary, but the development team are allways there to give you a hand, and finally everything goes smooth...

Re: Grails vs Rails by Marius Vasilache

Even if Servlet + JSP are faster, this doesn't mean you will end up doing faster applications in standard J2EE. If you are not experienced you will end up loosing this speed advantage and not to talk about productivity.

Graeme, can you detail what is the slowing down GSP views ? Is it SiteMesh, taglibs or something related to Groovy ?

Re: Grails vs Rails by Graeme Rocher

It is a number of different things. The parser is a bit naive so when producing multi-line static content it would do something like:


instead of a single call (using the platform dependent line separator of course)


And we could make better use of string interning and constants for static portions of content. Plus reduction of thread local lookups. So there are three areas of optimisation:

a) make the parser more intelligent to merge static portions into a single call
b) using string interning and constants for static portions of content
c) reduce thread local lookups and tag invocation overhead

Re: Grails vs Rails by Floyd Marinescu

Me Me, would you please use your real name on your InfoQ posts?

Re: Grails vs Rails by Marius Vasilache

Where can I change it ?

Re: Grails vs Rails by Marius Vasilache

I found it

Grails is the best by David Nelson

I´m still at my first steps at Grails development, but I can say that it´s really incredible.
The only issues that I can say it´s the lack of IDE support and performance.I´m already using the new IntelliJ plug in, it´s not done yet, but seems to be very cool. And the performance is not that bad.
Comparing to Rails, GSP/JSP syntax is a lot better than RHTML, I used to develop in PHP and ASP and I really rate those <%= %> in my templates. I prefer Groovy than Ruby to, much more readable, Java-like, better syntax, and also have a lot of cool features like native EL.
Thank you are doing an excellent job.

IDE support by serge ----

Graeme, Netbeans 6.0 has very nice dev env for ruby/rails, do you see something like this in the near future for Groovy/Grails (perhaps via Coyote project).

Re: Grails vs Rails by Jeff Bonnes

I'd have to second Nicolas' commments. Grails development is FAST. We wrote our website on Grails and it works great. We have had some performance bottle necks but have been able to sort them out by refactoring views and using more AJAX. Although there was not great IDE support, we still got it up very very quickly.

We also started a traditional Spring / Hibernate application about the same time that we are still completing with 3x the people on it.

Having worked on Grails and a traditional app at the same time, Grails wins hands down.


Rails DOES have a domain model by Bill Siggelkow

From everything I have heard, Grails is an excellent framework for Java web applications; however, I have to disagree with the following comment:
There is also no such thing as a domain model in Rails. Rails models are database tables. This is all well and good, but in enterprises the same domain model is often re-used in multiple applications both desktop and web. This is effectively accomplished in Java by packaging the classes with the mapping files in a JAR.

Rails applications do have a domain model in a similar way that Hibernate-based applications have a domain model. In my Rails application models, I use a mix of ActiveRecord objects and plain Ruby classes and modules. Rails supports both compositions and associations within an ActiveRecord model. For a simple example, I can have a Name class, which does not extend from ActiveRecord, that encapsulates the parts of a person's name and provides methods for formatting and parsing. I can reuse that Name class wherever it is needed.

As far as model reuse outside of the web application ... in practice, I find that this doesn't happen too often ... usually due to differences in the contextual use of the domain model. That being said, given Ruby's support for metaprogramming, I imagine that creating an ActiveRecord model that delegates to a non-ActiveRecord class object should be possible.

All in all, I have found it easy and natural to create a rich domain model in RoR applications. Rails applications lend themselves well to a thin controller/fat domain model approach.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

27 Discuss