We’re great fans of Grails so we were very excited when we heard about Roo. Both frameworks promise rapid application development but Roo claims to have no runtime overhead. Can it live up to the hype?

Whilst Grails and Roo both aim to simplify the developer’s life they approach it in different ways. Grails is built on top of groovy and adds a lot of “magic” at runtime whereas Roo is essentially a code generation utility.

Performance

The benefit of compile time code generation is of course performance. A Roo powered application will almost always be faster than a Grails powered app but the performance “hit” associated with Grails is not as great as people sometimes think.

When we have run into performance problems in Grails the bottleneck in invariably a couple of methods or closures which perform computationally expensive calculations. Groovy implicitly uses BigIntegers for division which imposes a big performance hit. Extracting such calculations to static java methods which use floats often speeds up execution time by as much as 90%. Another area where Grails performance is lacking is the rendering engine behind the GSPs and specifically the way tag libraries are used. Switching to another rendering engine can significantly improve performance.

Both Roo and Grails can be tweaked to improve performance without making changes to the code base. Judicious use of caching and transaction management will give significant performance increases for both platforms. The use of transactions is especially significant for grails apps because by default grails will try to create a transaction for every request which is far from ideal.

So in summary out of the box grails is considerably slower than a Roo powered app but with a bit of tweaking we have found that grails apps can come very close to “traditional” java ones and certainly acceptable for all but the most demanding of applications.

Skills

To make the best use of Grails a developer must have a good grasp of Groovy whereas Roo is pure java so there is no need to learn another language. This shouldn’t be underestimated, I believe that any experienced Spring developer will have no trouble learning Groovy … the question is do you have the time to learn Groovy. Top developers are in high demand and getting time off to study something new is often easier said than done!

Grails and groovy is not hard but to become proficient you do need to spend a fair amount of time with real world examples. If you are a java developer and you have the chance to work on a grails project I would say jump at it … you’ll love it!

In contract a competent java developer can be up to speed and developing productive Roo apps in days. The code that is generated will look familiar and you’ll feel confident to experiment to get the best results. Roo is also ideally suited to more junior developers who may not be comfortable with some of the more “esoteric” features of groovy and grails but just want a framework that will save them a bit of time.

Availability of libraries/plugins

Roo is built on top of Maven so dependency management is a breeze and there is an extensive library of code available. In contrast grails relies on plugins which have a limited availablity. Grails can be used with Maven but it’s a painful experience and not something we would recommend. This is an area where Roo wins hands down. Ide support for grails projects is also lacking, even Spring own ide (STS) doesn’t have a specific groovy editor and debugging a grails application is not for the faint hearted. Grails generates a lot of code at runtime so the code you see in your debugger bears little relation to the code actually running. This can be a major headache but careful use of breakpoints and logging statements can ease the pain somewhat.

Maintenance

We’re not big fans of code generation tools, my own view is that if you find yourself writing or generating a lot of boilerplate code and config there is something wrong with the structure of your application. The core spring framework has been moving towards convention over configuration in recent releases, annotation driven controllers are the best example of this. Roo builds on this but it’s nowhere near Grails in terms of ease of maintenance. We are still amazed at just how little code we need to write to deliver a fully functional Grails powered app.

We have not yet developed and maintained any production grade Roo apps but my guess is that it could actually act as an impediment to the long term success of the project. I say this because I suspect developers who may be under pressure with tight deadlines will tend to rely on the code generation rather than thinking how they can structure the application to minimize code duplication.

Conclusion

Grails and Roo are both great frameworks. The framework you choose will depend on your need for performance vs maintainability but ultimately I think the big factor will the level of skills in your team. An advanced developer will be able to develop amazing Grails apps that are far more maintainable than those developed using Roo. Junior developers will be able to develop a basic grails app but the moment you hit performance or threading issues you’ll need to climb quite a high wall. Roo can be used by developers of all levels to boost their productivity.