I’ve had the pleasure to use several web application frameworks for various web apps during the last few years (actually, sometimes it’s been a real pleasure, sometimes less so…).
After having done a most of my web application work in PHP and Perl before I decided to try something new for Topicalizer and so ended up with Python and TurboGears. While at first I was quite happy with this solution, especially with Python as the underlying language, TurboGears became a bit of a hassle later on when for some reason it started to behave differently in development and production environments. Besides, upgrading from some of the pre-1.0 versions was less than trivial, but this is what you buy when using beta software, so no complaints about that.
For another project we used Java (J2EE to be more specific) and JavaServer Faces for the view layer. The latter was a real relief as it allows the re-use of HTML and AJAX components without actually writing a bit of HTML or JavaScript. However, writing all the usual Java enterprise stuff like Hibernate mappings, XML configurations, PhaseListeners and DAOs was still less than satisfying.
Enter Ruby on Rails. I think, everyone who is into web development at least has heard of this framework written in Ruby by a developer at 37signals who is commonly referred to by his initials DHH.
At MetaSieve we used Rails for an eCommerce solution as well as for the prototype of our product, which already featured integration of Lucene and Nutch. As JRuby was far from being stable, let alone being able to run Rails at that time we resorted to a Ruby package called Ruby Java Bridge that pretty much did the trick.
Basically, we were quite satisfied with Rails. Developing web applications was finally fun again. No need for pointless configuration and boilerplate code anymore. Common tasks were very easy to accomplish and even high-level stuff like Java integration was possible.
However, one problem remained: Essentially being a Java shop and relying on various libraries like Hibernate, Spring, Lucene and Nutch we basically would always have had to write glue code in addition to the actual Ruby and Java code. For companies which depend less on Java libraries which simply are not available in the Ruby eco-system this might be less of a problem but for us this paradoxically meant writing more code in one place in order to write less (much less admittedly) code in another.
Finally, in 2007 we came across a shiny new web application framework by Graeme Rocher:
Grails, written in Groovy – a dynamic language for the JVM – and Java. Grails sports standard Java libraries like Hibernate and Spring for establishing principles like DRY and Convention over Configuration, which were made famous by Rails.
Since that time Grails has made quite some progress and can be considered mature and stable enough for production use, especially as the libraries it is built upon have been around for some time, too.
MetaSieve so far has used Grails for our GameSear.ch and ContentSieve online services and we intend to use it for everything else that’s leaving our shop at least in the near to mid-term future.
Finally, we have found a web application framework that suits our needs in pretty much every respect:
- Staying DRY and featuring Convention over Configuration like Rails
- Being able to write code in a dynamically typed language like Groovy and a statically typed language like Java just as needed
- Being able to draw upon the huge amount of mature third-party software that’s available for free in the Java eco-system (which probably is only rivalled by Perl in this respect)
The MetaSieve Blog 