Comparing Ruby on Rails to Grails
Ruby on Rails and Grails are competing for the rapid development market amongst Java developers. Yes, RoR reaches beyond the Java community, but a lot of Java developers are experimenting with it so that is where I’m focusing this initial comparison. This is by no means meant to be a head-to-head feature showdown, but more of a general adoption comparison between the two and what the future looks like for both of them.
Market Reach
Grails is by its nature bound to Java and will appeal to enterprise groups more then RoR because they are more likely to have application servers already in house that they can deploy their applications to.
RoR on the other hand isn’t bound to Java and has the potential to be as common as PHP in the general web hosting arena. Already several companies are allowing RoR applications to be deployed so the trend is moving.
This really comes down to general market and enterprise market.
General Market Winner: Ruby on Rails
Enterprise Market Winner: Grails
Design Approach
Ruby on Rails: RoR uses the bottom up approach where you define your model at the database schema level and RoR builds the model to match using naming conventions. You don’t even have to add the properties to your domain classes as RoR will add them based on the naming conventions of the db schema.
Grails: Grails uses the model-down approach where you define your model and it (or Hibernate technically) builds the schema for you. As I mentioned I don’t like this as a matter of taste since I don’t have as much control over the underlying model. To Grails’ credit, you can fine grain control the database schema by using Hibernate’s mapping, but what a pain.
Winner: Ruby on Rails
Ease of Refactoring
Both applications are tightly bound to the data model by their nature but they approach that model in completely different ways. RoR works from the database while Grails works from the domain classes and builds the database. Both can be configured to work with non-standard (their standard) schemas however.
I tend to not like being shielded from the database for a variety of reasons, but even with that RoR is much more flexible with regards to quickly refactoring the model. One thing I loved with RoR was I can have it running, add a column to a table, hit refresh and the field appeared on the edit form page. That is nice. It even knew when I wanted a textarea instead of a text field when I change a column type from varchar to text. That is what I call ease of refactoring.
Winner: Ruby on Rails
Supporting Libraries
Ruby: Ruby uses what they call Gems for libraries. There is quite a growing list, from accessing web services to command line parsing to database support.
Grails: Being that Grails is build from Java and then again on top of Spring, the list of supporting libraries is basically limited to anything written in Java, which is quite extensive. Not only does this allow for reusing custom built libraries, but utilizing the thousands of open source Java libraries out there.
Winner: Grails
Longevity
Ruby: Still fairly young, the RoR community is growing like crazy. Fueled by a desire to build quickly without a lot of overhead and to some degree the FUD surrounding JavaEE, Ruby has a pretty good future.
Grails: The future for Grails is going to be a bumpy one. First they have to appeal to the mass Java crowd, which is largely going towards Ruby as it is. Then you add JRuby to the mix with its growing compatibility with RoR along with Sun’s backing and it doesn’t look quite so good for Grails. I wouldn’t count it out just yet, but it will be a hard fight.
Winner: Ruby on Rails
Conclusion
From the looks of it, Ruby on Rails is a clear winner. However, RoR is still young and has some growing pains to get through much like Java did in the early days. Grails has a huge step forward in that if it can really get in front of Java developers it will have a bigger impact in the enterprise much early on. RoR on the other hand, via JRuby, will be able to run on the same platform as all those other Java enterprise applications and companies will benefit from a larger Ruby user base. In addition, RoR is already showing a presence in public facing applications and adoption (see 37Signals as an example).
The other area to consider is the general small company usage. There are tons of choices available when it comes to hosting on the LAMP platform, but with the bigger hosting providers now adding Ruby to the features list I believe the number of open source RoR applications will grow quite a bit in the next couple of years and slowly push out the PHP applications that dominate the small market space. This will have a huge impact on the number of developers that are fluent in Ruby further increasing its popularity.
In five years, Ruby may very well be the next Java, even beating out Java on the JVM.
Don’t miss anything, subscribe!
Did you enjoy this post? Why not leave a comment below and continue the conversation, or subscribe to my feed and get articles like this delivered automatically to your feed reader.
Comments
The Grails advantage for current Java developers is not to be overlooked and I mentioned it a couple times I believe. The point about binary compatibility is a good one and I only mentioned that in the sense of being able to utilize current Java libraries, but I didn’t mention the reverse, where non-Groovy/Grails code can be access Groovy code. Which of course is pretty cool too 
Thanks for the comments Raffaele!
Allow me to demonstrate how ridiculous this “adoption comparison” is, where you doing nothing more than conflating your personal preference and what you’re more familiar with.
”
I tend to not like being required to maintain the database for a variety
of reasons, but even with that Grails is much more flexible with regards
to quickly refactoring the model. One thing I loved with Grails was I
can have it running, add a property to a domain class, hit refresh and
the field appeared on the edit form page. That is nice. It even knew
when I wanted a textarea instead of a text field when I change the
‘maxSize’ domain class property constraint. That is what I call ease
of refactoring.
…
The other area to consider is the general small company usage. There are
tons of choices available when it comes to hosting on the LAMP platform,
but with java servlet containers being so ubiquitously available on the
majority of hosting providers I believe the number of open source Grails
applications will grow quite a bit in the next couple of years and slowly
push out the other applications that dominate the small market space. This
will have a huge impact on the number of developers that are fluent in
Groovy further increasing its popularity.
…
In five years, Groovy may very well be the next Java, with its seamless,
transparent integration with Java on the JVM.
”
I could rewrite every one of your paragraphs in that manner.
It’s silly of you to pose to seriously predict the “future”, strictly based on such trivial vagaries; which can each be just as easily spun the other direction. This is merely a very weak attempt at an opinion piece.
I appreciate that you prefer Rails ( although it appears you are limited in your understanding of Grails ), but come on – get real – you’re basically just blowing wind here.
Nice try, but you are off on a couple of things. First, while there are many java hosting providers, they are far outnumbered by the LAMP providers and many providers are not even considering using java but will consider using Ruby. The reasons may be do to not understanding Java but that isn’t the point.
Second, while I mentioned some of my preferences I didn’t take them into account in the actual comparison. You will never be able to be able to achieve the level of schema control by starting from a domain model (i.e. Grails). Ask anyone who has ever built a serious corporate application and they will tell you that ORMs can only go so far. I’m not a data model freak, I just know that there are a lot of data models for CRUD applications, that are very difficult to map correctly with something like hibernate (or JPA for that matter).
You make a couple of valid points which I give you credit for, however I know each tool equally well and I don’t claim to be an expert in either. To be fair it could be said that I should be biased towards Grails because I’m a Java developer and therefore biased towards Groovy and thus Grails. In some respects I do prefer Grails as it has more options that I like.
As for a prediction, I didn’t predict anything. I say “..may..” not “…will…”. I think it is a shame that Sun hasn’t given Groovy more respect and their recent endorsement of JRuby will only help Ruby in the long run. Personally I think the scripting support of Java 6 is great and having all of the languages that run on the JVM that we do just ads to Java’s future, but to ‘get real’, Java lives because of large enterprises unlike say PHP (yea, yea PHP is getting some love from IBM and whatever) and those enterprises will want to stick to whatever standards are around as much as possible. If Sun endorses Ruby over Groovy that helps RoR and not Grails.
I apologize that my post seemed a bit chippy. Was not intentional. (c8=
As far as hosting providers tending to provide rails support over, say, tomcat or somesuch – I’m not so certain, but that’s ok; I generally, as a rule, tend to have some level of control over all my servers; so I don’t shop around all that much.
You say that you did not take your preferences into account in the actual comparison, but your Design Approach and Ease of Refactoring appear to take nothing _other_ than your personal preference towards the model aspect into account; not to mention, they both seem to be somewhat (completely?) redundant as far as your explanation/evidence goes: they both contrast the difference in approach between the two frameworks regarding the model. ( you further fail to mention that Grails supports the same sort of “refactoring” you use in your Rails example ).
Anyhow, water under the bridge! (c8=
What’s more interesting is that you say you’re actually more biased towards grails due to being a java developer; this is funny because I prefer grails even though I had held a strong bias _against_ java for many years! I was just another perl hacker for 8 years before discovering ruby – and very much appreciated all the great things about that language. I took Rails for a spin, and just … didn’t quite jive with it, even though I loved ruby. I eventually, just for a lark, and only just recently, tried out grails and groovy – and instantly felt very comfortable! Funny how things work out… heheh
I even actually preferred the bottom-up approach in the ORM layer, tending to rather build my schemas by hand; the hibernate approach was completely foreign and a bit uncomfortable for me at first, but I’m now getting a handle on it and can appreciate one less context-switch to deal with.
Finally, however – you might be interested in knowing that middlegen integration is on the very near-term roadmap for Grails ( for the 0.7 release, slated in May/June or so ) — this will allow the bottom up approach you enjoy in Rails to be available with Grails. Pretty cool:
One last thing – you did not mention performance concerns at all in your evaluation; which I think is an important detail. Check out this recent benchmark:
http://docs.codehaus.org/display/GRAILS/Grails+vs+Rails+Benchmark
Although Grails may outperforms Rails to a significant degree, it will be interesting and fun to see how Rails on the JVM via JRuby will compare.
Kind regards!
No offense, but this is just sad. I know you tried to compare, but you did nothing more than state opinion on each one. And you don’t even have your facts straight! You simply do not understand the underlying technologies of Grails (hibernate, for one) to make any sensible comment.
Yes, RoR might well be the next PHP. Fine..take the market. Grails is going to be for serious development and serious projects.
Jason: Oh I understand enough of Hibernate having used it several times and while it is true that I do not like it overall, it definitely has its place. For what it does do it does do well, so I don’t knock it by saying “it sucks”. As an pure ORM it works great if you don’t mind living with the db schema constraints. Given that I have also built two ORMs myself I understand what it takes to do them. No they aren’t easy, no Hibernate doesn’t suck. It certainly has whipped CocoBase, Toplink, EJB entity beans, et al in adoption as an ORM tool. Props to the Hibernate team for that. I just happen to build applications where Hibernate either didn’t perform or was far too constraining.
If by “Grails is going to be for serious development and serious projects” you mean the ‘enterprise’ market I agree UNLESS JRuby really takes off and supports RoR really well. To call the current RoR applications out there not serious (such as the apps developed by 37Signals) isn’t fair though.
autocrat: Fair enough! I did see the roadmap about the middlegen integration and I honestly forgot to mention it, so you are correct there.
As for the performance I intentionally left that out because I thought I would get more backlash about it still being new, Java having a 10+ year head start, etc. etc. There was a time when Java wasn’t all that speedy and it took a few years before the JVMs came along that made it really shine. So to be fair Grails does have the advantage because it runs on those VMs and I’m sure Mongrel, etc. will catch up. Then again, perhaps we could be running Ruby on the VM and then we would have some real benchmarks!
Good debate gentlemen, thanks for the comments!
I believe your rationale for deciding to exclude performance is fundamentally flawed.
Re: “As for the performance I intentionally left that out because I thought I would get more backlash about it still being new, Java having a 10+ year head start, etc. etc.”
I would like to note that this is wrong. Technically, Ruby is actually only a few years younger than Java’s initial revs (and about the same in terms of publicly-released years), and certainly far older than Groovy; and that Rails is also certainly older than Grails.
I will admit though, that whereas the JVM has had popular exposure since a few years after it was publicly released, Ruby appears to only have had a popular presence since the appearance of Rails (and only recently received a VM). Furthermore, Hibernate has had more time than ActiveRecord to mature.
But companies don’t choose a development platform on the hopes that performance will improve, but that the performance is sufficient and that the development effort is reasonable. It seems to me that Rails may be a more mature framework and will be appealing to shops where performance is not a top priority, but that Grails has the performance advantage, and can work with pre-existing Java web development efforts, and is built on top of very mature pre-existing Java frameworks, and therefore is more appropriate/comfortable for development when performance is more important, but development speed cannot be sacrificed.
I’d personally like to see the RoR developers respond to Graeme’s performance comparison. If that means that they run the test using JRuby, a better CGI, or some newer version of a RubyVM, so be it. At this point, I believe that the ball is in their court to prove that they can match Grails performance.
You are correct Daiji, Ruby itself has been around for quite a while although it hasn’t gotten mainstream acceptance until Ruby on Rails made its big splash on the scene as you mentioned. I should have made that point as well.
I think initially smaller companies will lean towards RoR while the bigger ones go towards Grails if for no other reason that Grails is Java based and thus there is a wider developer base (for the time being) which is a consideration when it comes to staffing. With regards to the bigger companies, it will be the developers themselves going towards Grails more than a ‘company’ decision. I’ve certainly been one of the developers before that started using a new framework for an application for whatever reason (RAD, curiosity, whatever) and the company didn’t care as long as it ran on their chosen platform, i.e. a JavaEE server and it was documented. Smaller companies might be more inclined to have specific reasons for one over the other, especially if that company is basing their product on the software being written (again I point to 37signals).
There is enough buzz and interest in Rails however that I think the performance side of it will increase at a faster pace than Java’s did back in the day.
I am a Ruby-biased system admin for a web hosting company that specializes in Java. “Groovy on Grails”, besides sounding like a bad joke, is doomed against Rails in the long run. Ruby is potentially a lot better suited for small applications, especially in hosting environments with limited memory. Trying to tack Rails-like functionality on top of the beastly JVM is a recipe for frustration IMO.
Check out http://eapps.com for both Java and Rails done right and with GENIUS support. That way you can still host the last of your Java apps whilst you learn RoR
Now now dantebronto be nice… I believe I’ve mentioned before that RoR will beat Java in the ‘public’ app space, much like PHP does today. However, in the enterprise market it will take far longer for Ruby to penetrate and Java will be king for quite some time.
As for the ‘beastly JVM’, well JRuby is moving along quite nicely and almost has complete support for Ruby on Rails applications. Not to mention that Graeme has already shown that early testing of Grails outperforms Ruby on Rails.
I’m aware of eapps BTW. I just looked and they have some good stuff since I last saw them.
Hi,
A fantastic read, it is very literate and informative. Many thanks….what theme is this you are using also.
Grails won
Past three clients: McKesson, TimeWarner, now AT&T… All moved from legacy Java, then spring, now Grails… Many thanks to SpringSource!
You will get a watch for free if spending more than 109$
Welcome to visit our web http://www.rolexclassic.com/Classic_Watches/363/2695.Html You can always choose the watch which you love best.
We have many kinds of replica watches ,such as rolex watches, chanel watches, breitling watches, cartier watches and so on.. The quality of the watches and the service we provide must be the best
You don’t even have to add the properties to your domain classes as RoR will add them based on the naming conventions of the db schema.
I love this article very much. I will certainly be back. Hope that I will be able to read more informative posts then.
Today, a watch is not only a timepiece for checking time, but also a adornment that can prettify yourself and reflect you personal status.
I recommend is to have several good watch.
They not only work fine and affordable.
http://www.buyswissreplicawatches.com/replica-swiss-longines-watches_c105.html Replica Longines Watches
http://www.buyswissreplicawatches.com/replica-swiss-louis-vuitton_c108.html Replica Louis Vuitton Watches
These are all good developments for Java developers. Hopefully Java developers would be happy with the changing scenarios. Thanks for sharing this news with us.
Marriage is a lifetime thing that need us to devote our time to run for it. And it is a unforgettable forever of the marring moment. Do you have any ideal what kinds of wedding dress you have, what kind of wedding shoes will match your wedding dress? What a important thing that if you choose a wedding dress careless you will regret for the rest of your life
http://www.b2b-free.com/
http://www.b2b-free.com/christian-louboutin-sandals-c-90.html
http://www.b2b-free.com/christian-louboutin-mary-jane-pumps-c-105.html
http://www.b2b-free.com/christian-louboutin-evening-shoes-c-88.html
Louboutins shoes was popular with women from 18 years ago,cheap christian louboutin and customers can buy it in shops as well as shops and Internet stores.cheap christian louboutin shoes And moreover, wholesale christian louboutin are available in some areas,christian louboutin sandals such as American Stores located in New York City,christian louboutin pumps Los Angeles, Las Vegas and Orange County, with another system for the Design Miami Area. Meanwhile, christian louboutin shoes also in hongkong.
Michael Kors Biography:
Born Karl Anderson, Jr. on August 9, 1959 on Long Island,michael kors outlet New York, Michael Kors knew at a very young age that he wanted to be a fashion designer.michaelkors-outlet.net He began designing at 19, while he was attending the Fashion Institute of Technology.michael kors sale By 1981, people had already taken notice of his chic designs and began scooping them up for sale in such high-end department stores as Neiman Marcus and Bergdorf Goodman.michael kors watches These michaelkors-outlet clothes were sold under the newly-launched Michael Kors label.
R4 Card
Acekard 2i, Howdy terrific blog! Does running a blog similar to this take a massive amount work? I have no knowledge of programming however I was hoping to start my own blog in the near future. Great information source, please write more about this.
Another style christian louboutin shoes sale recorded the last few of years, unless you are already residing on the exceptional style christian louboutin outlet store to our own, will in all likelihood be christian louboutin outlet mall return en force of style factors within of the previous few of years christian louboutin pumps.
http://www.maxonlinestore.com we are company the wholesale nike air max ltd Introduced in 2002, the Nike Air Max Limited (LTD) sports a sleek and stylish look and a visible Max Air sole. The visible air sole provides cushioning and and shock absorption while the rubber out-sole provides optimum traction. and durability. Aside from its lightweight and durability, the leather upper is ideal for style comfort. The Air Max LTD is still a popular shoe and is sold in most Nike retailers.
The informal article encouraged me very much! Bookmarked the site, very excellent categories everywhere that I see here! I really like the information, thank you.
“RoR is already showing a presence in public facing applications and adoption”
It’s the same for Grails. Maybe not so many as for Rails, but some public websites have been written in grails:
http://grails.org/Success+stories
The interesting, is that at least one of the companies behind a couple of those sites are in the fortune500. Not so bad for a yungster like grails (some 3 years old).
Also, there are some other considerations in favour of grails. It’s based on Grails, and grails has a fundamental advantage over JRuby: it’s binary compatible with Java, and specifically designed from the ground up to be run on the JVM. You can put all the effort you want in the development of JRuby, but it will never be completely binary compatible with java.
Another one: syntax. The syntax of groovy is familiar with that of java. With this, I mean that you can convert existing java code to groovy with little effort. I’ve tried it myself, with a simple class. Cut+paste, converted two for loops (groovy 1.0 does not support classic for loops), and go. A big, big advantage for javists, since it avoids the task switching issue (for greater productivity) and allows them to reuse knowledge base.
Anyway, the great fight between grails and rails will probably be on the “tool support” field.
Cheers