Rails vs Grails

I had a week between projects so I decided to take a deep dive into the Ruby on Rails (RoR) ecosystem and compare it against my earlier experience with Grails (from the Groovy, Java and Spring camp).

First, the 10,000 feet view:

1. Both enable Rapid Application Development. You can get a slick, non-trivial application developed in less than a day using either approach.
2. Both rely on a Domain Specific Language (DSL) to do the heavy lifting. The domain, in this case is web enabling your application. The DSLs are what allow scaffolding, Domain creation and persistence (among other things). They are written in Ruby for the Rails environment  and are bundled as ‘gems’. Similar functionality is written in Groovy for the Grails environment and are bundled as plugins.
3. Both encourage a test driven approach (test first), although, it seems that RoR may have been slightly ahead of the curve on that front.
4. Both rely on  several community projects to make your application enterprise ready. Rails relies heavily on ‘helper’ projects written in PERL, JS and (*nix) shell scripting whereas Grails relies on ‘helper’ projects from the Java/Spring ecosystem.

Now let’s take a closer look:

1. Agility: In RoR apps incremental development (agile techniques) are encouraged by adding properties incrementally to the model. This is handled via a ‘migration’ in RoR on the db gem. Correspondingly, in Grails, to handle incremental db changes you would have to resort to external projects like liquibase or flyway (which, btw, are totally effective in a non-web environment also).
2. Persistence: Rails persists the model using a gem called activerecord. In Grails, persistence is carried out by the GORM (Grails Object Relational Mapping) plugin.
3. Performance: I’m not totally sure of this one because I do not have benchmark numbers.. But based on the fact that Ruby is interpreted (and remains so), whereas Groovy is compiled into Java and then into bytecode, I’d say that Grails outperforms an RoR app, all else being equal.
4. Testing: Testing is ingrained in the fabric of RoR. It is available via a DSL that encourages Behavior Driven Development (BDD). Tests can be written on the client-side as well as the server side code. Popular frameworks are RSpec and Cucumber.  Grails relies on the JUnit framework and related test runners like Mockito, PowerMock, EasyMock etc.
5. Tooling: IMO, tooling in RoR is severely lacking. In fact, in some sense, the use of tools is looked down upon (maybe it’s because of it’s rich lineage with unix based systems). So we are left with mainly command line interface based usage for RoR dev. In the Grails camp, Spring Source Toolsuite has terrific support for all Grails development including code completion, testing, plugin discovery and installation and deployment.
6. Services Access: RoR apps typically access all backend services via RESTful calls. Grails does that too but has the added advantage of being able to inject Spring managed services (with all other proxies) injected into Grail controller classes. So not all access has to be RESTful.
7. Build: RoR: Rake, bundler, Grails: Gradle, Ivy, Maven
8. Version Control: RoR is firmly committed to Git (no pun intended:) whereas Grails is rapidly cutting over to Git with some projects still in SVN.
9. Authentication: RoR: Clearance, AuthLogic, CanCan, Devise. Grails: Spring Security Framework
10. MVC: Both offer a clean implementation of MVC2 via controllers, views and domain objects. Although I like the fact that domain objects in Groovy do not have to inherit from a superclass (As is the case in RoR where domain objects inherit from ActiveRecord to implement persistence). This keeps the domain model clean altho’ it can be argued that for a Grails app, GORM annotations can still mar the pristine domain model
11. ServerSide UI generation preprocessors: RoR: Embedded Ruby (erb), Grails: Embedded Groovy expressions, Tiles, SiteMesh
12. UI Templating: RoR: There are several available amongst Haml, CoffeeScript and HandleBars, Grails: css framework plugin called Blueprint (amongst others), SiteMesh
13. Language: Ruby is a dynamically typed language. So is Groovy. And therefore the niceties afforded to dynamic typing are available to both. However, based on the debate of which is superior: dynamic or static typing, I just love the fact that Groovy is an extension of Java and so I can fall back to the safety of Java if I want to. So you have dynamic typing if you need dev time flexibility, and static typing if you want run-time certainty. That, IMO is a killer feature, right there!
14. The center of ‘gravity’: This, IMO is the main difference between the two technologies. Grails comes from the Spring camp, where there is already tremendous support for non-web based initiatives, like Enterprise Application Integration, Batch processes support, Social APIs, Data (No-SQL persistence), Persistence (JPA/Hibernate support), Tooling (Roo, STS) and Queuing (AMQP, MQ). So while Groovy has become known (to me, at least) via Grails, there is life beyond Grails too.
    While Ruby is a great dynamically typed language, there were not many projects built around it (no useful DSLs) till Rails came along.  And so the ecosystem that is available is built mainly to support Rails. I have to clarify, that I am not stating that before Rails came along, there was no support for non-web based applications. There was. However, it was not as focused and organized as we see in the Enterprise Java world.
    Put another way: Grails is domain centric. Rails is web centric.

In Conclusion

Rails has got a very strong, vibrant and vocal user community. But I think the euphoria is based of the earlier success of Rails when the developer community moved from the tedious and chaotic world of web app development to the (almost) magical world that Rails offered. Since that time a lot of water has flowed under the bridge, so to speak. Several convention-over-configuration, rapid application development “frameworks” have sprung up and leading the pack in the Java space is Grails with the support of the Spring behemoth behind it. Here is a figure that supports that point of view. But, here‘s a Google Trends chart that (at the time of writing) says the complete opposite!

So my take on this is:
If you have the need to build a web based application starting from scratch, pick one based on the expertise you have in your team. Both Rails and Grails will deliver quickly.

However, if you want to build an application that, at it’s core, may not be web-based (or minimally web based), adopting Grails may be the better option in the long run. Or if you have an app that is already out there and all you want to do, is web-enable it and you have Java expertise in-house, Grails may be the way to go.