JRuby on Grails?
There is a small ongoing debate about Ruby on Grails... the Grails founder, posted in thoughts on the topics too.I don't know were Graeme takes it's numbers about Grails apps that are in production, but I guess that Ruby on Rails numbers are much higher. He argue that for a Java shop, Grails is much better framework than JRuby on Rails. His main argument to support this is that it will take less training. He seems to forget that to learn Grails (even if it's closer to Java than Ruby) also require some training. I would even add that learning the convention for framework like Rails or Grails is where most of the training is required... Learning the language is easier than learning the conventions.
In my point of view, JRuby on Rails has much more potential than Grails. First, Grails is playing catchup with Rails (still waiting for Migration in Grails). Second, Grails biggest strength reside on the integration layer between well know frameworks. However, these same frameworks are Java based and they come with the same limitations that the Java language has. Limitation that are not present in Rails because of the dynamic nature of the language it's build on.
Why would it be a good idea to run Rails on JRuby? Yes, integration with Java is a plus. But performance may be part of the answer. Ruby is not very fast (but it should get a lot faster very soon with the use of a Ruby VM), Java is quite fast. So running Rails on Java can make it faster. Even with Ruby VM coming along, JRuby may be faster because Java VM had a lot more work done in the VM performance than Ruby will have when it get it's own VM. If I'm able to run a Rails app in Tomcat or Weblogic, it will also have more appeal for existing Java shops. It could also give you the benefit of having access to existing Java libraries that have no equivalent in the Ruby world.
Instead of working on making JRuby as a language to run on top of Grails, if integration with existing libraries (like Hibernate) is desired, I think that Integrating the existing library in Rails would be much better. One could easily write a simple layer around Hibernate so one could have model objects inheriting something like HibernateRecord instead of ActiveRecord. The dynamic nature of Ruby could make this HibernateRecord behave the same way as an ActiveRecord. As for presentation framework, I don't think that component-based framework are such a good idea anymore. So there is no need to ever want to integrate them in Rails.
Graeme argue that Sun should not longer put resources in Phobos because the project is unpopular... I could argue that same thing about Grails... Compared to Rails, Grails looks like the unpopular guy in the schoolyard. But I won't do that... While I personally don't see why would someone would choose Grails over Rails, I thing that competition between frameworks is good. And when Grails will start to innovate (instead of playing catch-up) then it may become really interesting. The unpopular guy of today can always become the most popular guy of tomorrow (this is the Ruby and Java story).
4 comments:
Unfortunately I think you're a little confused Emmanuel. Rails most certainly has more users than Grails, but in terms of users deploying onto the JVM Grails has far more.
Grails also has interest from the enterprise, which is a complete deadend for Rails. How do I know? I delivered a 1-day workshop to 14 Grails newcomers mostly from the banking and insurance industries. I see and hear of organisations adopting Grails in their enterprises everyday.
As for Migrations, since Rails uses a database centric domain model they are crucial for Rails. Grails on the other hand embraces domain-driven development where the domain model drives the db and hence Migrations aren't nearly as useful.
In the end though use what you enjoy. At the moment Rails is a non-entity on the JVM, whilst many JVM (read Java developers) are using and enjoying Grails today. There are live deployments of Grails going live everyday (http://grails.org/Success+Stories).
Unfortunately your opinions are an exact reflection of a typical Rails user:
http://www.anyware.co.uk/2005/2007/03/16/blind-loyalty-the-futility-of-grails-vs-rails-no-framework-is-immortal/
Hi Graeme,
I'm not confused... I never said that Rails on the JVM has more deployment, I just said that "Ruby on Rails numbers are much higher".
As for Migration, it is false that Rails is database centric. It is domain driven as much as Grails (or must I say Hibernate)(there is no business logic the database with rails - if you just use basic migrations, you will not even have referential constraints in your database, unlike Hibernate). Most of the time, Java domain objects has a direct one to one relationship with a database record. Maybe ActiveRecord is a bit closer to the database design by default than Hibernate, but in reality (dynamic nature apart) you will produce similar classes using both for the same domain.
Migration are much more than a feature to create tables, it is a feature that allows you to evolve your tables (granted, Migrations are database centric). The Java world could greatly benefit with the use of migrations. In fact, many people are using them to manage their table on Java projects. Saying that they are not as useful is a lack of understanding of what they are worth.
Last, I'm not a typical Rails user... In fact, I do a lot more development in Java than in Rails. I like Java a lot, I like Rails a lot. While Grails offer a nice integration layer for popular framework, you can achieve the same kind of framework integration with JBoss Seam. But this is just that... Nicely integrated frameworks. This gives an advantage above selecting your own stack, but they do not have the productivity advantage of Rails.
Does this mean that I dismiss Java or Grails... No way! But Grails need to go over the rails-like-but-on-Java-so-its-good-for-java-shops moto and start innovating. Maybe you don't think that Migration are useful, but can Grails provide a way to do something similar for your Domain Objects? Or even better, change the way we design our presentation layer, or some other stuff we haven't thought of yet.
And if I'm wrong in my evaluation of Grails, no problem... I'm intelligent enough (or so I think) to reassess my position in the future (I once was very exited about MDA... I can tell you that it's no longer the case).
Here's something else to consider - Rails is truly terrible as your project increases in complexity. At the company I work for, we use Ruby on Rails everywhere, and as soon as there is serious load, the whole thing starts to buckle BADLY. Aside from that, if you don't keep 100% up to date with new Rails releases, the wild swings in the API's make it virtually impossible to guess with any degree of certainty what is going to break. And the touted dynamic nature of Ruby is often a bad thing - I can't mention how many places I've seen Rails actively modify the behaviour of core Ruby functionality, and then change it again with another release, so arbitrary things like date functionality becomes incredibly quirky.
One other advantage you failed to mention for Grails is that you can use native Java code, too, so you're not stuck with 1/2 baked "Ruby-only" ways of doing things (ActiveResource SUCKS SOOOO BADLY at forcing this point), or crippling voids in functionality (crypto anyone?)
Nice bblog
Post a Comment