Brian has 10+ years of experience as a technology leader and architect in a wide variety of settings from early startups to Fortune 500 companies. With experience delivering SaaS solutions in business intelligence, artificial intelligence and VoIP, his current focus is big data and analytics. Brian leads the Virgil project on Apache Extras, which is a services layer built on Cassandra that provides REST, Map/Reduce, Search and Distributed Processing capabilities. Brian is a DZone MVB and is not an employee of DZone and has posted 62 posts at DZone. You can read more from them at their website. View Full User Profile

Rails vs. Grails

12.16.2011
| 33313 views |
  • submit to reddit

I was recently asked the question: Rails or Grails? I needed to summarize the key differences and industry sentiment. This was my response.

Before I make any subjective comments, let me start with some objective metrics I found:
http://www.expectationgap.com/posts/13

Now for my sentiments, I believe there are three key-dimensions: momentum, cloud-support, and people.

Momentum

Rails has the momentum as evidenced by the number of committers and plugins available. Many of the rockstar developers I know are all now developing in Rails, supporting that community, etc. The underlying Ruby language is incredibly expressive and allows dramatic productivity improvements. (write less code that can do more)

Only a handful of rockstars I know are developing on Grails. Typically, those developing on Grails are in enterprises or markets that are comfortable with Java and they want to continue leveraging that investment. (infrastructure, app servers, production support, etc.) Grails/Groovy does have the advantage that It can continue to leverage the output of the Java community (e.g. Spring). The better projects within the Java community are quickly integrated into Grails. For example, Grails uses Hibernate and Spring Security under the hood. As those projects improve, so will Grails.

Cloud Support

Rails and the cloud go hand in hand. Again, of the rockstar Rails developers I know, nearly all of them are running on virtual hardware owned and managed by others. Some of those let others manage the entire application server / platform (e.g. EngineYard). In contrast, all of the Grails development I know of is running on hardware (virtualized) owned and managed by the company itself in their own data centers (or rented space). As mentioned before, this may actually have been the motivating factor to select Grails. That is not to say that there isn’t cloud support for Grails. And now that VMWare owns SpringSource, this may change rapidly now that enterprises will have a trusted name (in VMWare) to host their Grails applications.

People

Rails has the momentum, more committers and potentially a more active community, but lets not fool ourselves -- there is an army of labor out there to sling Java code. Offshore resources are readily available. The market for Rails is developing, but demand isn’t yet high enough to drive consulting companies to substantially increase their supply. As one of my good friends put it, “I’d love to develop in Ruby, but Java pays the bills.”. It is that sentiment, that has may limit the availability of resources.

However, even with readily available Java resources, that doesn’t guarantee the availability of Groovy resources. Both Grails and Rails require a slightly different mindset. If you take a Java developer and tell them to code in Groovy or Ruby, you’ll end up with Java code using Ruby/Groovy syntax. (not good) But at least the tooling, debugging practices, and libraries will all be familiar.

And just to stoke the fire...

Here are my entirely subjective scores:
Momentum: Rails (9) vs. Groovy (4)
Cloud Support: Rails (8) vs. Groovy( 5)
People: Rails (6) vs. Groovy (8)
---------------------------------------------------
Rails (23) vs. Groovy (17)

Source: http://brianoneill.blogspot.com/2010/12/rails-vs-grails.html

Published at DZone with permission of Brian O' Neill, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Gavin Hogan replied on Fri, 2011/12/16 - 9:15am

 

So your effort to stoke a fire compares a framework to a language arrrrghhhhh, ruby!=rails and groovy!=groovy. 

So ignoring that...

I would like to point out to you that the cloud support agrument is pretty weak.  There may be more people running grails app on dedicated resources but that could indicate many things (available capital, risk tollerance, existing resources ), not simply rockstar status. The ease at which a grail application can be deployed and scaled in the cloud is stellar.  The core grails team maintains the plugins for both Heroku and CloudFoundry and the AWS plugin is very good too, these plugins make cloud depployment a breeze.

Is rails better than grails - what does it matter? Both rock 

Good work on the FUD, keep it up. 

 

http://blog.heroku.com/archives/2011/12/15/grails/

http://blog.springsource.org/2011/04/12/one-step-deployment-with-grails-and-cloud-foundry/ 

 

 

 

 

Marko Milicevic replied on Fri, 2011/12/16 - 10:13am

Personally i have no direct experience with Rails myself, though i know there are many happy Rails users.  

But i have been learning Groovy/Grails for some time, and i amazed with everything that has been done in Groovy ecosystem, particularly with Grails.  It is so beyond anything i have been exposed to in the past.

Btw Grails 2.0 just got released - so happy!-)

Guido Amabili replied on Fri, 2011/12/16 - 11:05am

I'm maintaining a grails application developed by somebody else and the performance are incredibly poor......though not really important because it's deployed in our intranet with few users. Maybe you write less but spend more time optimizing, it's my guess b/c I am not an expert in Groovy/Grails.

Though I ve heard Rails performance are not stellar either.....

Gavin Hogan replied on Fri, 2011/12/16 - 1:30pm in response to: Guido Amabili

@Guido sorry to hear that dude, sux to have to maintain something so inefficient.  I think it is fair to say we have all seen apps that fit that description written in every language we know.

Marko Milicevic replied on Fri, 2011/12/16 - 1:57pm in response to: Guido Amabili

@Guido was that runtime performance?  I'm going to guess it was likely writen non-optimal.  Most of the underlying code for Grails is straight up Java (particularly Spring and Hibernate).

Benchmarks are hard to judge, but this particular one shows Grails to perform favorably...

http://www.jtict.com/blog/rails-wicket-grails-play-lift-jsp/

Otengi Miloskov replied on Sun, 2011/12/18 - 12:00pm in response to: Guido Amabili

The Framework and System are fine the problem are the ex-developers that coded that crap usually is always like that.

Otengi Miloskov replied on Sun, 2011/12/18 - 12:02pm in response to: Marko Milicevic

Awesome benchmark, I can see Grails is like Scala Play performance, that is awesome for Grails.

John David replied on Tue, 2011/12/20 - 10:58am

They are completely different technologies sharing a name pattern (e.g. Java and JavaScript). It was smart at the time to name the web framework built using Groovy "Groovy on Rails" (later asked to change its name) to get attention in a space saturated with web frameworks. One key fundamental difference (besides different programming languages) is the use of ActiveRecord in Rails versus Hibernate in Grails.

George Jiang replied on Wed, 2011/12/21 - 5:57am in response to: John David

Just as .NET MVC is a Rails clone on .NET, Grails is a Rails clone on JEE (both borrowed a lot of ideas from Rails such as routing to controller actions, resolving view file location etc).

Unfortunately, with Grails, you can only program in Groovy, not Java. While with .NET MVC, at least you can program in two mainstream langeages on the .NET platform, i.e. C# and VB.

My view is that the Rails way of doing MVC seems so natural, yet scalable to larger projects. Those pre Rails Java MVC frameworks , such as Struts 2, Stripes, Spring MVC (including version 3), just feel so awkward once you had a tast of Rails or one of its clones.

Mike Hilding replied on Thu, 2012/01/05 - 12:42pm

The original article is more than a year old. Dec-2-2010 to be exact. Do you think it still holds true today?

Beaumont Muni replied on Thu, 2012/01/19 - 10:15am in response to: George Jiang

Your assessment of Java not codable in Grails is absolutely wrong. Have you tried it? It's totally doable. Groovy and Java code can be intermixed within the frame work. You can import your java classes inside the Grails framework so you don't have to reinvent everything. Infact there are source directories for pure java classes as well. A common thing for companies to do is to bring in and use use java domain classes within the framework as well. This works well for migrating domain objects from more older systems. The framework was written to accommodate the current  existing java enterprise ecosystem, except that now you have Groovy with all it's cool dynamics.

I have worked specifically with the Grails framework since 2007  after over 15 years of experience in the java enterprise environment. Would I go back to java? No way ... . I  have done some Ruby/Rails as well and did not really like their approach of handling the mapping process of the model objects. I personally like Grails because it uses the domain driven model very well, and allows me to be more handsoff form the database. Groovy compiles to java byte code just as java itself does. I think Ruby is a cool language and I enjoy it's  terseness. Groovy is pretty good too and has a lot of cool dynamics about it. Having said all that, my personal feeling is that you go with what you are comfortable with and what you like. At the end of the day, it boils down to money and time. 

Eric Weimer replied on Wed, 2012/02/29 - 11:56pm in response to: George Jiang

Hate to see misinformation: In Grails you can program in groovy OR java OR Scala OR Closure, etc.

 

Eric Weimer replied on Thu, 2012/03/01 - 12:09am

The nice thing about Grails is that it is based on Spring and Hibernate, two solutions that are known to be scalable. Although an excellent framework, Rails has historically had difficulty scaling. 

 Yes Groovy runs slower than Java most of the time. However the cases where you need extra hardware to run Groovy are rare. 

 In addition, extra hardware is much less cheaper than developer costs. Both Rails and Grails can save up to 30% of developer time, which is much less costly than an extra cpu.

 One so-called architect suggested I give up Groovy since it is "too slow". Almost made me laugh, as Java was also considered "too slow" by many when it came out, as was SQL, databases and COBOL!

 Both Rails and Grails are excellent options. Java and C# developers will find Groovy syntax easier to pick up than Ruby syntax. Not a good reason to pick Groovy over Ruby, but one that is likely to happen nontheless.

 Personally I like both and either one is clearly better than legacy languages/frameworks.

George Jiang replied on Thu, 2012/06/07 - 8:39pm in response to: Eric Weimer

Of course you can mix Java code in a Grails application. My point was that you cannot code your Grails application in Java alone, you have to write some Groovy code and there aren't many developers fluent in Groovy.

 While with ASP.NET MVC, you can write all your code in C#, which is a mainstream language.

 I will not look at Grails until Groovy becomes a mainstream language, or Grails applications can be developed without writing a single line of Groovy.

Leo Jacsion replied on Fri, 2012/12/21 - 2:03am in response to: Gavin Hogan

 We don't just offer cheap Web Hosting  in India but also reliable and superior support. All our hosting accounts come with a control panel which gives you total control of your webspace, domain.Web Hosting Choice is a free research guide to help users choose the right web host for their personal or business website.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.