Grails vs. Rails

Ruby On Rails and Grails are two popular MVC webframeworks. Rails uses the Ruby language, and Grails uses Groovy. In this post I compare Grails vs Rails.

Introduction

Ruby On Rails (in short just “Rails”) is a webframework that uses the Ruby language. It uses a push MVC design pattern, which means that a controller/action receives a client HTTP request, then creates or search (in a DB) for model objects containing data, and forwards those objects to the view where a HTML page is rendered for the HTTP client.

The other webframework, Grails, is also a push MVC webframework that uses some ideas of Rails. In fact, it was previously called Groovy On Rails. Grails uses the Groovy language instead of Ruby.

About the comparison

The way I look at these frameworks is influenced by my prior knowledge and preferences:
-I have a Java background
-I strongly prefer static typed over dynamic typed. (Why would you hide important information in your code about types if you need to document it anyway.)

I’m not an expert in these frameworks. Maybe I don’t even know the existence of some basic features. So if you think I forgot to mention something important, then leave a comment πŸ™‚

Grails and Rails, in common

  • Development, production and test modes.
  • built-in webserver
  • quick boot/startup
  • hot deploy / class reloading without restarting the server
  • ORM (Object Relational Mapping) / Active record
  • lots of plugins, that can be downloaded from the command line. a plugin manager
  • nice URLs
  • model, view, controller, and test generators
  • popular, an active community
  • easy to learn / use
  • The language supports: string interpolation, multi line strings, raw string (no Java escape hell), closures
  • Full stack frameworks
  • screencasts
  • console for additional testing
  • easy to configure
  • productive
  • Builders. Configuration can be done in Groovy/Ruby files that look like normal configuration files. Easier to read than XML.
  • Books are available
  • quick releases
  • Dare to drop features. Can be good or bad, but I like it when features are dropped in order to keep the framework good.
  • Build tasks
  • Very easy to create tags/reusable HTML components. (Something you cannot say about JSF.)
  • Convention over Configuration

Grails vs. Rails

  • Documentation. The first thing that frustrated me about Rails was documentation. How do you learn Rails? Grails has an excellent up-to-date User guide, but on the Rails doc webpage you have API, Books, some outdated not-working external third-party tutorials, and how-to’s. But no userguide….. It’s very frustrating when you are halfway your first Rails steps in a tutorial (that is directly linked from the official main Rails docpage), and find yourself having to Google for solutions/workarounds because the popular Rails tutorials are so outdated that it doesn’t work anymore. If you want good learning material, you are forced to buy a RECENT (e)book otherwise you’ll find code that doesn’t work.

    API documentation is probably better in Rails than Grails because they have examples and more info in it. Rails also has wiki pages, which can be useful when looking for specific problems. Grails on the other hand has a userguide/tutorial that is very suitable for beginners, it is also useful for a quick reference. Grails website has some pages that have duplicated info about the same subject, sometimes these pages are outdated, and thus conflicting each other. e.g. the Grails pages about validation.

  • Grails uses other solid frameworks underneath it, like Hibernate and Spring. Frameworks that are well known in Java enterprise. These frameworks have a lot of features for the Model and controller, and thus give Grails a lot of features.
  • The View layer in Rails has a lot of features; there are a lot of view helpers/functions, which can be very handy. e.g. link_to_unless_current, which creates a hyperlink to an URL unless it is already the URL of the current page. Another example is Rails’ RJS, which allows you to write Ruby code that is outputted in Javascript.

    But Grails has IMO too less helpers. On this point, Grails is very weak compared to Rails. e.g. a select html input in Grails doesn’t allow selecting more than one item. Also, implementing error textfield highlighting using default Grails tags is very cumbersome.

  • Both frameworks are popular and have an active community. Rails is more popular; it existed before Grails and has inspired other frameworks. Rails has more jobs.
  • Grails automatically adapts the DB when creating/changing model attribute names, but this feature might be a bit unstable sometimes, since updating existing model classes is not very stable in Hibernate. (It is hard to determine whether a new found attribute is a new attribute or a renamed existing attribute when no versioning is used.) (Hibernate can also generate Java classes from an existing DB.)

    Rails uses Migrations to change the DB. A migration is a Ruby file containing almost SQL-like commands; it’s like writing pure SQL, but you have to write it yourself. Every migration has a version, and commands to change versions, so Rails has a DB versioning system. This can be very useful when you need to update the Production servers’ DB in a consistent way.

    Grails has a more object oriented approach; it shields/protects you from low-level sql. Where Rails gives you more SQL control when creating tables, and Rails allows you to control db versions.

  • Grails has GORM (Grails Object Relational Mapping) for making, saving and retrieving the domain models from the database. Rails uses Active Record.

    Grails (GORM) uses Hibernate (one of the best ORM frameworks) underneath its layers. When making a model class in Grails, you make a plain basic class with the attributes defined in it. When making relations between model classes, you’ll have to use special variable names that define the relations. Like belongsTo, hasMany, mappedBy and embedded. Maybe this can be done with Groovy annotations in the future? Grails automatically saves adaptions you make to a model class, to the db. Although, as mentioned previously, it uses Hibernates hbm2ddl, so for safety, you have to check manually that the DB table is what you expected when changing/renaming existing attributes. Validation of attributes is also put in the model class.

    Rails Active Record differs a lot from Grails GORM. A Rails domain class/entity is composed of two files, a migration file and a Rails model class file. All model attributes and datatypes are defined in the migration file and/or database, using an SQL wrapper. So that the migration files can be directly translated to pure SQL; writing a migration file is like writing SQL DDL (CREATE statements). At this point the associated Rails model class file is empty. From an Object Oriented point of view, this is an ugly approach; the attributes are defined in SQL/db instead of the domain model class itself. It also makes IDE autocompletion and refactoring hard. It also makes it cumbersome for yourself to lookup the attributes for a domain model class; you have to look in multiple files for it! Making relations is done both using SQL foreign keys and is similar to Grails, putting special variable names or methods in the model class: belongs_to, has_many etc. Validation is also done in the model class. When you add new attributes to a model, you can use a new Rails Migrations to propagate it to the DB. Which basically is a SQL change table add column command.

    So the Domain model in Rails is database based, instead of OOP based like Grails. I know OOP and Hibernate, so I like starting with OOP for the domain model and generate the DB from it. Btw Hibernate can do both; it can reverse engineer/generate Java classes from an existing DB, and it can generate the DB from domain model classes.

  • Both have books available. Rails has more books.
  • Grails has Implicit Dynamic Scaffolding (optional), you don’t have to write the view. The view (html) is generated, and changes automatically when you add new properties to the model. This can be useful when learning the framework. But when coding a webapp, you probably write the view yourself. Rails had Implicit Dynamic Scaffolding in the past, but they removed it because it’s only useful for beginners. Both frameworks also have explicit scaffolding.

    I prefer the scaffold generated by Rails, but Grails has column sorting.

  • Grails uses Groovy, so you can use new or existing Java classes/libraries, and thus have both dynamic and static typed. You can even code pure Java in Groovy classes, or mix them. Rails uses Ruby, but Rails also has third party JRuby, which allows you to call Ruby classes from Java classes and back. JRuby is less integrated with Java than Groovy. Like Grails, with JRuby you can run a web-app in a Java EE environment. JRuby is probably only interesting for those who want to use existing Java classes.
  • Grails is faster than Rails, but with JRuby, Rails can increase its speed. The ruby Merb framework (similar to Rails) will be merged with Rails in the future. Merb is faster than Rails.
  • In Rails, it’s very easy to pass objects from the controller to the view, because of Ruby. For example in Rails:
    		Rails:
    		*** ProductController ***
    		@product = Product.find(1)
    		@category = Category.find(1)
    		

    In Grails you have an extra step with duplicated names.

    		Grails:
    		*** ProductController ***
    		product = Product.find(1)
    		category = Category.find(1)
    		['product' : product, 'category' : category] // last line in controller action. It defines an identifier twice.
    		
  • Rails has a lot of different names for the same thing, which can be confusing. This is caused by Rails pluralization; controller names and db tables are automatically named in plural from a singular name. For example, when you have a domain class for a shipping address. In Rails you’ll find names:
    • ShippingAddress (model classname)
    • shipping_address (model filename, attribute name)
    • shipping_addresses (controller filename, attribute list name, db table and migration name)
    • ShippinAdresses (controller classname)
    • Pluralization can be turned off, but is enabled by default, it’s the Rails way of naming.

  • Grails uses Jetty as default webserver in development mode. Rails uses Mongrel by default, and Webrick in the past.
  • When generating a Grails project, the project will still use some script files from the Grails_home dir. Rails copies these files, which makes it easier to adapt Rails projects without influencing other projects.
  • Grails uses Java underneath it; it uses more memory than Rails. This probably makes hosting a Rails app cheaper than a Grails (Java) app. (Hosting can be cheap when you use a Virtual Private Server.)
  • Grails has an expression language, like JSP. In a Grails view, you can use:
    • <%= product.getPrice() %>, or
    • ${product.price}

    Rails doesn’t have an expression language, so you can only use <%= product.price %>. I prefer using expression language when possible; it keeps the view cleaner.

  • Grails uses Groovy, which IMO is easier to learn than Ruby, especially is you already know Java. Groovy uses a syntax that is found in other languages, like C++, Javascript and PHP. Ruby however differs from that. Also, in Ruby, there are often multiple ways to do something. Sometimes the language remove one way, while leaving the other. This can be confusing. Ruby, also has no method overloading.
  • Rails feels more matured than Grails because of it’s better View layer. It also is already at version 2.2 where Grails is at 1.0.
  • Rails has a built-in benchmark, profiler. Grails has it using third party plugins.
  • Both Grails and Rails configuration files are easy to read. Grails probably has an easier syntax.
  • Rails inspired other frameworks, like Grails.
  • Rails seems to be released/updated more often. This might be because Graeme Rocher (a Grails developer) was working a Grails book the last couple of months.

Specific for Rails:

  • Easy to change from a single Rails version on a system shared by multiple projects, to a single Rails per project config. So that you can run multiple Rails versions if needed.
  • Very REST by default. nested url resources like /articles/1/comments/5/edit
  • security, authenticity_token against cross site request forgery.
  • You need to restart the webserver when you add a scaffold for a model, because routes.rb gets changed.
  • Rails’ Active Record uses a lot more SQL in code than Grails (Hibernate).
  • Changes in routes.rb requires a restart. Thus adding new resources (like REST controller for a model) requires a server restart.
  • The DB drives the Model. E.g. default model values have to be specified in the DB.
  • Cumbersom to find how you can code in Model classes as Plain Old Ruby Objects. For example you can’t use the initialize method?
  • Rails with Capistrano and Mongrel make it easy to implement load balancing. Not sure if this is also possible with Grails.
  • Rails has special url_path variables/methods, which makes writing urls easier. For example, it automatically has variable/methods names like edit_article_url(article) that translate to the correct URL.

Specific for Grails

  • Grails: Sitemesh breaks the OSIV (Open Session In View) pattern. So you cannot use full GORM in layouts. Something that really needs to be fixed.
  • No Java annotations in Groovy?
  • (Groovy) console/shell tool cannot work with def keyword?
  • Hard to debug errors messages
  • doesn’t work out of the box with all third party servlet based software. For example, UrlRewriteFilter doesn’t work.
  • less secure? Via a html form POST hackers can set properties for new objects even is those properties aren’t defined in the form itself. (This happens when the new MyDomain(params) is used.) FIX: use command objects or bindData method. Not sure if Rails has a better solution.
  • Jsession id’s are sometimes visible in the url. e.g. when using the flash for messages.
  • Grails: Looking up a pretty url given a controller and action and id, isn’t possible? Only the default url scheme is used?

Summary and my preferences:

  • I like both Grails and Rails.
  • I prefer the Groovy language over Ruby, especially because Groovy supports static typed and Java. Although writing in Ruby is also cool.
  • Grails really has to do something about the view layer. Rails is a lot better at this point.
  • I dislike that Rails domain model is database centered. I doesn’t feel object oriented. You cannot use plain Ruby classes, you have to look in the migrations for model attributes. You cannot simply use an initialiser/constructor of the model in Rails, for example when you want to set default values. How do you make a constructor that receives parameters? Ruby also doesn’t support method overloading. The Rails domain model feels limited in a OOP way.
  • Rails feels more matured.
  • Grails is more enterprise and Java EE focussed, using Spring and Hibernate.
  • Grails focusses on the use and incorporation of other well known frameworks using plugins, making it possible to use other webframeworks if needed. For example: Struts, Wicket, Flex, GWT and Echo.
  • Rails project configuration is more flexible.
  • I should have a better look at JRuby.

17 thoughts on “Grails vs. Rails”

  1. Hi, interesting writeup, lots of valid points. Lots of invalid or wrong ones as well,
    like:
    Capistrano and mogrel makes load balancing easy (nonsense. deployment tool + webserver != load balancing)
    ActiveRecord uses lots of SQL
    it automatically has variable/methods names like edit_article_url(article) (they are just methods. try adding (). they will work.)
    etc.

    The comparison is ok otherwise, just very opiniotated and not precise at details.
    You got me with grails though, i will make time to check them out (i will try to overcome my usual “omg java” alergic reaction)

  2. Well, let me give u my opinion in brief:
    Grails might be the paradise for java developers, but as for me I’m not a java developer, so i had to stuck with java, groovy, spring and hibernate sometimes to find answers. While in rails, it’s all about ruby and ruby only.
    Also, grails is ‘opinionated’ and not that modular, a thing rails is trying to avoid by merging with merb team.
    RoR has more than 40 books in the market, while grails has 2 or 3.
    The community is far bigger in rails, go to the irc channel and check the support you can get, while grails has no active channel at all…

  3. “You cannot simply use an initialiser/constructor of the model in Rails, for example when you want to set default values.”

    If you want default attributes, create a constructor and pass in your (optional) attributes. In the example below, if there is already an attribute with the key :name, that will take precedence.

    class Product ‘Undefined’))
    end
    end

    Also, the whole point of dynamic typing isn’t just to save space declaring variables. It’s about being able to pass around any object that handles certain messages without needing a lot of interface garbage attached to it. Check out “duck typing”. Pretty powerful when you get the hang of it.

  4. Sorry, looks like your comments just strip out code instead of escaping it. Just email me if you want me to show you how to create a constructor with default values.

  5. What I think would be more interesting than a checklist comparison, would be an experience report by some who has actually used both frameworks for non-trivial projects.

  6. I have used both grails and rails and I strongly prefer rails even though I work in Java and have strong Hibernate and Spring experience.

    Ruby is simply a more elegant and powerful language than Groovy. The metaprogramming functionality is truly a joy to work with.

    Rails testing is easier and more comprehensive; grails 1.1 is addressing that but it’s still behind. Doing BDD in Ruby/Rails is really nice with frameworks like shoulda. I’ve tried easyb in groovy but it’s not as integrated and polished.

    The Ruby and Rails communities are bigger and more mature. You can easily find solutions to most problems.

    Grails using hibernate is not always a benefit. I found myself having to write my mappings in xml many times since the hibernate functionality is not supported yet in grails so I lost all the benefits of grails.

    Rails view and ajax support is better than grails. Grails does not have anything equivalent to RJS. Rails built in helpers are great.

    Rails REST support is almost non-existent in grails.

    Rails routes are extremely powerful and superior to the url mapping in grails.

    Grails does not support migrations.

    Grails/Groovy does not have anything equivalent to gem. I’ve used ivy on my grails project and I know that maven is now supported, but maven is a pain to deal with.

  7. Hi Amigos,

    I remember, 3 years ago, to Bruce Tate and his “texanian” prediction: “RoR is the Java’s killer !!!”…

    As a Delphi (is it death?) then, Java was a way to survive, and no just that, I really like.

    From 2005 to now, I have seen Java waking up, with stuff like (the failed) trails, stripes, etc. etc.

    Trying to read and learn Ruby and Rails, I found out Groovy then Grails and the only thing I regret is the poor support in NetBeans for GaG tools, as Sun seems to be concentrated on JRuby.

    Grails is for Java Developpers, and in my case for a limited former Delphi developpers.

    I have a question: Does Ruby have the same set (very big set) of mature tools and frameworks as Java has? I have changed of platform 4 times in the last 20 years (I was a DBase and Clipper programmer 1n 1998), and the main reazon why a had choosen Java is for things like Spring and Hibernate, now the basis of this wonderful framework: grails.

    I put to work a set of Grails/Groovy applications in 2008, all the time I got the support of tools and frameworks as JFreeChart. maybe Grails is not a grown up as RoR, but its value is based on the Java Platform as it is solid.

    ALL THE BE>ST IN 2009

  8. I have worked with Rails recently I love Ruby as language. And I think that Rails ActiveRecord is work of art.
    The one thing I really dislike in Grails is it’s name – Groovy on Rails – Grails. As the point from where I see it the whole groovy and grails is created just to have Rails to the Java world.
    But my opinion is no impartiality.

  9. I think Django is better than both of them. It has alot of good things out of the box. Plus the best thing that Rails and Grails have πŸ™‚

  10. Interesting comparison. I use both frameworks … I am a java developer and use Grails for personal projects but work in a RoR shop where I use Rails all day long. As a developer I am very partial to an approach that is more object orientated. Rails is more data model centric and not so much domain model centric as Grails is in it’s approach to the same thing … so that’s why Rails uses models with migration etc … and Grails uses domain classes. Grails approach tends to flow better with application design using the vertical domain driven model and furthermore I like to stay away from doing SQL if I can. I think Rails 3.0 with datamapper has the right approach along these lines which would help cut down the use of migrations … which is ugly. Making changes to domain-classes should automatically allow the frame work to change the database table. That’s where the strength of the frame work comes into play. GORM in itself is getting to be very powerful. It would be interesting to see where datamapper comes into play in this area.

  11. Thx for this article.
    I have been through all of the comments, and I can summariwe what REALLY MATTERS for me ONLY when comparing Rails and Grails

    Grails Pros
    – Groovy based on Java and Rails based on Java Fwks => It gives HUGE ways of extensibility, scalability and workarounds (if stuck with Grails). And I am a Java developer. Also, overloading is available (not in Rails)
    – Domain model centric vs Data model centric for Rails. No deal with SQL, changes to domain classes are automatically done in the DB
    Attrubutes in domain classes are defined in one file only and refactoring is easier
    – Grails has an expression language
    – Grails is faster than Rails (but needs more memory)

    Rails Pros
    – View layer is strong compared to Rails (RJS)
    – REST by default.
    – Rails is more mature : more doc, more help from the web, more stable?, more secure?
    – Easier to debug (Grails is known for cumbersome error messages)

    My winner: Rails…meanwhile πŸ™‚

  12. Eh … all I can say is whatever floats your boat … but you pay for the consequences of your choice. Choosing a solution based on the merits of the language is not enough. Yeah … we all like Ruby because of it’s terseness and the fact that you can write a line of code in 12 different ways or implement additional methods to a collection as opposed to 5 in some other language on the same collection object… yet you pay for it down the road in terms of scalability. That’s a known fact … and is being experienced by facebook, twitter … etc … to mention a few … All that RoR has done for Grails is to provide the paradigm of convention over configuration, a much needed move for the enterprise environment. That’s a great contribution and the right direction and approach.

    It seems that David H. Hansen … didn’t think about the Vertical Domain Driven Model so much or understand how IoCs work to resolve latency and dependency issues faced in a large scale enterprise distributed and service oriented environment while designing his framework called Rails. For a while, the main scalable solution in Rails was with JRuby, and that’s because of Java. Look it up … if you don’t believe me. There are new versions of ruby out but none of them have come up with a truly scalable model. That’s where it all ends and falls short. So both frameworks look the same form the top … but inside they are two completely different animal. If you’re a java developer you should revisit the Grails solution seriously.

    I like Grails and Groovy because it’s Java underneath … proven to be scalable. It has tons of “enterprise proven scallable” plug-ins that takes minutes to implement. The mixture of both the static and dynamic environments allow for easy migration of and enterprise solution. And wiring your services to an IOC is cake unlike the normal enterprise environments. The IoC container called spring manages services for better scalability. Coding standards are required in most places so you’re not just coding a line in 12 different ways .. yes that affects performance. Rails main approach for scalability for a long time was to to focus on an IT solution of configuring systems that integrate load balancing. In spite of the growing Rails community … etc, the open-source community behind Java is enormous and has been forever with solutions that’s been proven for over 20 years. Now cloud computing along with File systems implemented by Open source Apache solutions like Hadoop is taking things front and center. Besides Grails and Groovy is backed by VMWare and SpringSource the largest enterprise player in the market … using years of proven technologies. Again … think about your choices and if you’re doing that for a company … do it with some serious consideration because that company’s future depends on your decision.

  13. *** yet you pay for it down the road in terms of scalability. That’s a known fact … and is being experienced by facebook, twitter … etc … to mention a few … ***

    Facebook doesn’t use RoR, brainiac. And twitter was one of the fastest growing sites on the Internet. You are GOING to have scaling issues with any system in that situation. The problem was solved very quickly and they REMAIN on RoR, with some back-end functionality offloaded to Scala, which is appropriate.

  14. *** No deal with SQL, changes to domain classes are automatically done in the DB ***

    This is NOT a “pro” for Grails. Downright frightening, in fact.

  15. Very nice comparison. For me the deciding issue was complexity. Grails has followed a “best of breed” philosophy in picking the best of every component they could choose, including: Hibernate, String, Tomcat, Log4J, Maven, and the list goes on. Each one of these rightly deserve books written on them. For an Enterprise application at an organization with many developer, the power behind all of these components seems like a good thing. For a small organization, the risk is that the complexity of these components might bury the small organization. Consequently, I am a Java developer learning Ruby and Rails.

Leave a Reply

Your email address will not be published. Required fields are marked *