Marc Palmer

I say to myself "Mmm i wish I could track via an RSS feed or something my Apple order status so I know when my lovely new Macbook will arrive."

Lo and behold:

I’m gobsmacked. Apple should promo this widget in the Apple Store! Not only that, it works for Amazon and other shipping companies. The author is a genius!

Get the widget here

Graeme and I put a little work into getting some initial figures comparing Grails and Rails performance.

Grame has put these together into a benchmark document on grails.org

I fully expect a bit of a firefight over some of this but tried to be as fair as we know how – we are certainly not Rails experts so there may be some idiomatic approaches/tuning that can be done. However we didn’t necessarily optimise the Grails tests maximally either… so I am sure debate will range for some time. We always believed we would see this kind of result because of Java and Groovy’s non-interpreted nature – despite performance improvements being required in some areas of Groovy dynamic method invocation and string handling. Hibernate and the mature Java VM are also paying dividends for us.

We did find during the tests that there is some performance tuning to do with GSP view rendering, as there appear to be some bottlenecks related to heavy taglib usage.

Here’s the requests per second result for 1000 requests across 50 concurrent clients, updating 3 random records (doman objects) and returning a programmatically generated XML response:

In a nutshell, in each of these tests, Grails mean request time is lower than Rails in every case, in some by quite a bit. Grails has not been optimized to any degree yet.

I just hope people realise this isn’t intended to start a flame war. People are asking us for figures, and here are some. Of course if comparing Grails to a pure Java application we might see better performance for pure Java than Grails, but this is not a like for like test. To a degree the mantra with these new-generation frameworks like Rails an Grails is that you are happy to trade off a little performance for massively enhanced productivity. Shorter time to market etc.

There was a bit of untested code (AKA bug) in the SvnImport script draft. File is updated to draft 2 which definitely works… I just committed the Static Resources plugin to grails-plugins SVN.

Get it here

I’m going to try to keep this terse, in order to get the points across clearly.

Ruby/Rails zealots:

Rails is great for your apps, you are happy and have no scalability/integration problems. Good for you – keep with Rails. The existence of Grails does not preclude you using your favourite tool. However continuing to whine about how Grails is just "cloning" Rails or how it is not mature enough, or X this or Y that – it is blind loyalty talking. There is a clear place for Grails in the landscape of software development.

Whenever Grails is mentioned, someone loyal to Rails, who has surely had it solve some hard problems for them gracefully, comes out of the woodwork to dismiss it. This is just failing to recognise the different areas in the development market, different requirements, and the fact that Rails will not be the ONLY framework people use!

There are dozens and dozens of frameworks in use today. Rails has a higher profile than most  because of its clever marketing and introducing some great concepts like conventions to the masses who were suffering aneurysms as web application development continued to get more and more complex.

This kind of thing is totally futile, and its getting a bit dull. Get a world view, please!

Here’s a sobering thought. In 10 years time we may be lucky to find anybody still using Grails or Rails – something else even better will be here, in the same way that 10 years ago Rails and Grails were not here.

What has been here for more than 10 years though is the Servlet API  (2.1 was released in 1998!) and others in Java land. Well established, highly functional, forming the base of almost every Java-land framework out there. I bet Servlet API will still be around in 10 years, and Java VM based solutions will still be using it under the hood.

Much is made of Groovy’s immaturity vs. Ruby – how long have the Java APIs Groovy uses been around? They form the nervous system, organs and limbs of millions of applications worldwide. The language is just the heart that pumps the blood around. You need a heart to live. You need a body, to actually do interesting things.

Please, no more "Groovy sux0rs, Ruby r00lz", it’s rather irrelevant. Right tool for the job and all that.
 

I have put together a Grails svn-import target to tackle the tricky issue of initially importing your grails projects into an SVN repository.

Grails stlll messages around with a few files in your project source tree and this can confuse SVN or CVS and cause issues.

This script uses the "in place checkout" technique with SVN to avoid having to add all the project files, then remove a whole bunch from the repository afterwards. This means you must have an existing directory in your repository for your project to go in, and it should be empty, so when it is checked out  "over" your new grails project, nothing happens except your project is now considered a working copy.

The script excludes everything under web-app/WEB-INF/, web-app/plugins/ and plugins/core as these are generated/maintained by Grails – using the svn:ignore property mechanism.

Preconditions then:

1. You need a repository with a directory for your project (you can svn mkdir a dir for it on the server using the server URL)
2. You need SVN commandline tools installed
3. You may or may not have success on Windows (not tested).

You just create your Grails project, then: grails svn-import <svnurl>

Currently it doesn’t handle params for username + password…
Get the script here.