Rodrigo Rosenfeld Rosas
How do Rails and Grails differ?
A while ago I’ve written on why I prefer Rails over Grails, so be aware that this is another biased article.
That old article is already outdated since Grails 2 was released, and I was asked to update that article. That was my original idea, but then the comments wouldn’t make sense anymore, so I decided to write another take on Rails and Grails comparison. But this is a completely entire new article and not just an update to the old one.
Misconceptions first
Java is rock solid, while Ruby is not
I never understood this statement although I’ve been constantly told this for a long time.
Both languages were first released in 1995, more than 15 years ago, so why wouldn’t Ruby be considered as solid as Java?
Dynamic languages aren’t reliable
I have no idea why some people think that getting some program to compile is any indication that it should work.
Certainly those people don’t include Kent Beck and Erich Gamma or they wouldn’t have developed JUnit back in 1994, even before Java 1.0 being publicly released by Sun Microsystems.
So, as far as you understand that you need automated tests in whatever language you choose, it shouldn’t matter if the language is a static or a dynamic one.
Java written code runs much faster than those written in Ruby
How much? No one answers me that question. They think this way: “Java programs are compiled, so they must run faster then sofware written in any interpreted language”. People should really be worried about how fast they need their application to be before choosing their framework. If they can’t measure, they can’t compare performance, this is pretty obvious.
If you need a web application, you should be able to benchmark for your actual scenario before choosing a language and web framework. Also, if your application is very JavaScript intensive, it shouldn’t really matter the performance of the server side for many applications.
A typical web application will fetch data from some kind of database, do some parameters bindings and generate some HTML, XML or JSON result. This usually happens really fast on any language or web framework, so you shouldn’t be really concerned about language performance for web applications. Most performance improvements will be a result of some design change rather than a language change.
So, it is more likely that the framework design is more important than the language itself. If some language allows programmers to easily write better designed code, it is more likely that a framework written in such language will perform better. You should really be concerned on how fast you can develop your solution with the chosen framework/language. And I really don’t believe anyone can be as productive in Java as in any other dynamic and less verbose language.
Grails is the only Rails-like framework alternative for the JVM
Haven’t you ever heard that you can run Rails in the JVM through JRuby, a Ruby interpreter written in Java? The Rails test suite goes green on JRuby as well.
Too much talk, bro, go straight! So, what are the differences?
Reuse of software vs monolithic
Grails is built on top of the well known Spring framework and Hibernate, and integrates to Maven and Ivy.
Rails was originally considered a monolithic full-stack framework, with very few dependencies on external libraries. This has changed a lot since the Rails 3 refactoring, but somehow people still see Rails as a monolithic framework.
Integration level
While both Rails and Grails will reuse external libraries, Rails seems to be more well integrated to them than Grails.
This is very noticeable in the case of Hibernate integration on GORM, the Grails Object-Relational Mapper (ORM).
Rails uses by default the ActiveRecord library as their ORM solution, that implements the Active Record pattern in Ruby.
Hibernate, in the other side, adopted the Data Mapper / Unit of Work (Session) pattern.
I won’t cover the differences, merits and shortcomings of those patterns as it is out of the scope for this article and there is plenty of information around the web about them. I’d just like to state that you can opt for the DataMapper library in Ruby if you prefer this pattern.
The important thing here is to point that Grais will try to hide the Hibernate Session for newcomers to Grails and make some developers believe it implements the Active Record pattern, since the Data Mapper pattern add complexity for simple applications. The documentation will only cover Hibernate Sessions after explaining about Domain Modelling. This topic is so important for avoiding issues with Grails that it should be the first one as it can lead to several unexpected results.
If you’re planning to to use Grails, don’t do that before reading the entire documentation for GORM and this series of 3 articles about GORM Gotchas. This will save a lot of your time in the future.
GORM has bad defaults for newcomers and you’ll be surprised by when data is persisted and why you can’t call save() directly in some GORM instance in a background thread. That is usually the situation where you learn about the Hibernate Session if you haven’t read the entire documentation before.
On the other hand I haven’t found a single “gotcha” for the ActiveRecord gem, used by Rails as the default ORM implementation. Also all libraries used by Rails are very well integrated.