Grails vs Rails... The number game just started!

A first Grails vs Rails Performance benchmark has just been published The benchmark shows that Grails is faster than Rails. Rails developer Jared Richardsons commented on some flaws with the benchmark (aren't all benchmarks flawed in some way? And as the benchmark author said, the benchmark is not about scalability).

But looking at these numbers, I found that Rails is not far behind Rails. And I find that very encouraging for the Rails community. Yes, I would expect much better performance on the Grails side... Most of Grails is Java code. Java code running inside a modern JVM should run pretty fast. But beside the insert test (which I guess is significantly slower due having just one Mongrel instance running), Grails is not very far ahead Rails. Rails is mostly Ruby code. The Ruby interpreter is just that, an interpreter. There is no just-in-time compilation, no enhanced optimization for often used code in Ruby.

I can't wait till we have Ruby running on some VM (maybe the JRuby team will run the same benchmark and give us their numbers) and I guess we will see some great improvement on the Rails side (I guess that just rerunning the benchmark with multiple Mongrel instances will close much of the current gap).

This may be the very start of the Grails vs Rails number game!

Oracle acquire Tangosol

It looks like Oracle just acquired Tangosol! This must be great new to Cameron Purdy... I guess it was a long deal in the making.

I always feel kinda mixed up when I see great small Company acquired by huge companies. The vision of the Davids is often being blurred by the Goliath's. Can't wait to see Cameron's post on his blog to get some more details on this acquisition and what it'll mean to Tangosol.

JRuby on Grails?

There is a small ongoing debate about Ruby on Grails... Graeme Rocher, 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).

Running application instead of application servers

Most of the time, Java web application are deployed on their own instance of an application server. Within shops that uses server virtualization, this approach is extended to have one virtual server per application. This is done to ensure that an application will not adversely affect another one running on the same physical server.

However, application server products always assume that you may deploy many application on the same server. Configuring the application server is then a lot more complicated than what would be required to configure just one application.

If most of the time we deploy only one application per application server, why do we not bundle application server in our application instead of installing application server and then configuring our application on top of them?

Here how I would see how it would work :

1. Develop the application as usual (deploying the application on an application server),
2. Use some tool provided by the application server product to create an installation/update package :
1. The tool would have a Wizard like interface (but you would also be able to run from the command-line after saving the settings from the Wizard),
2. It would ask for which application to deploy,
3. Based on the application deployment descriptor, it would preselect application server features that needs to be available,
4. Provide an interface to select additional application server features to activate,
5. Ask for default configuration parameters for the application (datasource, ...),
6. Generate an interface (web, fat, console) to configure that application when installing/updating it,
7. Generate the necessary installation script,
8. Package the whole thing into a platform specific package (DEB or RPM for Linux, MSI for Windows, ...),
3. Install/update the application on the targeted environment using the generated package.

Using this approach has the following benefits :

1. Smaller installation footprint. If the application server does not need to be installed with all it's feature activated, then they should not be installed,
2. Easier installation/update process for those who have to maintain the system,
3. Easier configuration has only configuration options required for the application will be exposed.

Food for thoughts...