For my class on internet systems development, I had to evaluate a Java web framework. I chose Grails. The reason is that I find Java development to be incredibly painful. I cut my teeth on PHP and when I started programming in Java I was shocked at how long and tedious it was to do anything. So at first I was all, “Dude, why are we writing anything in Java? I could have this application done all by myself in three weeks in PHP. Instead it’s taken a team of three six months to do!” Soon, as I worked for a corporation and the life and creativity were slowly crushed out of me, I became resigned to Java. Now I simply jump at anything that promises less traumatic development, which is exactly what Grails does.

What It Do, Nephew?

Grails, according to their website, is “an open-source web application framework that leverages the Groovy language and complements Java Web development”. What that really means is that it’s a knockoff of Ruby on Rails (Groovy on Grails? Are you serious?) that is built on top of Java. Why would anyone want to do that?

Let’s talk about why Ruby on Rails has made such a splash. First, they have amazing marketing. But really, it’s because it makes web development much less painful. At one end of the spectrum you have PHP, which is ridiculously fast to work in but in the long run will probably cause you headaches with maintainability. At the other end you have Java, which is insanely difficult to work in but forces you to write code that in the long run will probably be easier to maintain. Rails seems to aim between these two and create an environment that is fast and easy to work in, but one that will also not be incomprehensible six months down the road. And they’ve done it: the very success of the project is a testament that they’ve achieved what they sought after.

Sounds great, right? The only problem is that everyone already writes Java apps. This means that all the developers are heavily invested in Java, all the server and database administrators are heavily invested in Java, and all the buzzword-compliant bosses are heavily invested in Java. You can’t just throw all that accumulated investment away in the hopes that the grass is greener in Railsland. Enter Grails: All that stuff that’s great about Rails, but in Java.

Let’s face it: Java development is hard. It’s really difficult. It takes a long time to get up to speed on how to do it, and even then it takes a long time just to build a product. The development cycle is forever long:

1. Make a code change.
2. Wait while it recompiles.
3. Wait while the server redeploys everything.
4. Oops, no, that wasn’t hot-deployable. Wait while the server shuts down.
5. Wait while the server starts up.
6. What was I doing?
7. Oh yeah, test that your code change worked.
8. It didn’t? Crap. Back to step 1. Where’s my IDE window again?

Contrast this to development in a dynamic language like PHP or Ruby or Groovy:

1. Make a code change.
2. Test that your code change worked.
3. No? That’s cool. Back to step 1.

(If you are interested in the philosophy of agile development, there is a free book on getting started with Grails by Jason Rudolph. The foreword by Venkat Subramaniam is a fantastic introduction to the topic and really expresses the essence of agility and what it is that Grails is trying to accomplish.)

“But wait!” you say. “I thought you said everybody was already invested in Java? How can we switch to Groovy, then?” The key thing about Groovy is that it is a dynamic language that gets compiled down to Java. This means that you can write all your code in Groovy and take advantage of that fast development cycle, but at the end of the day, nobody knows the difference because it’s all Java bytecode, and the JVM doesn’t care who made it.

What’s In That Stuff, Anyway?

Grails makes heavy use of the Model View Controller paradigm. When you write a program for the Grails framework, you write it in the Groovy language and you write three types of things: models, views, and controllers. This isn’t different from how you’re “supposed” to write programs using other frameworks; the difference is that in Grails you have to. It’s cool, though, it actually makes things easier.

Grails has a special URL structure that allows it to understand what methods of what controllers you’re calling. This is where that convention over configuration bit comes in. You don’t have to tell Grails what to look for; you build to what it’s already looking for. The following diagram, taken from the Getting Started with Grails book, explains what Grails is looking for:

Grails URL Structure

The controller part of the URL corresponds to, get this, the controller that you write. The action refers to a method in the controller and will be rendered by a view of the same name. The record ID refers to an instance of a model that the action is going to work with. (Obviously you can pass whatever parameters you want, it doesn’t have to be an ID and it doesn’t have to refer to a model. But this is a ‘typical’ example.)

So what’s in Grails? In the introduction to the above mentioned Getting Started with Grails book, the author says this:

At its foundation, Grails is supported by proven technologies. Hibernate, a de facto standard in the software industry, provides the basis for the object-relational mapping (ORM) in Grails. The Spring Framework supplies the core of the Grails Model-View-Controller (MVC) architecture and enables powerful dependency injection. SiteMesh brings flexible and effective layout management to Grails. And, let’s not forget Java. Because of Groovy’s excellent Java integration, Grails applications not only have direct access to the multitude of Java libraries, but also to the enterprise services (distributed transactions, messaging, etc.) provided by JEE application servers – an absolute necessity for many applications.

The Holy Grail or Just Another Cup?

Fast development, built on proven technology, integration with Java. Grails has the potential to be TEH R0X0RZ. But does it deliver? Time to get dirty in some code and find out.

Installation was breezy: download, put it somewhere, make sure it’s in your path, done. Then I made the mistake of running ‘grails help’ which took 12 minutes while it compiled and cached its scripts. Fortunately it’s reasonably fast after that, but it was a bad initial experience.

I started out with a nightly snapshot of 0.5, since it’s the latest and greatest. I created an application and ran it just to make sure everything worked and sure enough BAM massive exception. Oops… well, maybe the nightly wasn’t such a good idea. Back to the website, grab 0.4.2. This time it worked, hooray! I decided to work through the examples provided in the Getting Started with Grails book. Now, I’ve used Ruby on Rails before and it’s obvious how much Grails copied from Rails. That’s fine, it’s supposed to be a competitor. Some things seemed to be harder than necessary in Grails, but that could be because the book was written for an old version.

Grails delivers, if only barely, on its promise of a fast development cycle. I noticed that I was able to change views and controllers without restarting the server and my changes just showed up. Trying to generate a new scaffold for a new domain object caused the server to get lost and I had to restart it. Modifying a domain object by adding a field while the server was running caused my changes to show up in the database (the column was created), but then exceptions caused it to not work, even after I reverted the changes. After I restarted the server and my changes still didn’t appear, I realized that I had forgotten to regenerate the controller and views for my domain. Well, we already determined that regenerating that stuff doesn’t work at runtime, so you’re either forced to bounce the server or write the code yourself so that it does work at runtime. (Or use dynamic scaffold generation, but that’s really slow.)

For kicks I decided to write my own class in Java and see if I could use it from within Grails since, you know, that’s pretty much the whole draw. I made a simple class that just had a single String property with a getter and setter. After I figured out where to put my code so that it got compiled, I imported it (using a plain ol’ Java import statement) in a controller, created an instance, and set the property with the setter. Then in a view I displayed the property with standard EL syntax and it worked. Pretty cool!

Overall performance of the server and grails scripts were sluggish. Generating all the scaffolding for a class took more than two minutes per domain object. I mean, that’s not horrible, and it’s still faster than writing all that stuff by hand, but while you’re just sitting there staring at the screen, it’s an eternity. Page views were really slow. I’m sure they would be faster in production (since it won’t be regenerating everything every time), but it slows down that fast development cycle. Once while using the dynamic scaffold generation, my browser timed out. It got better once I actually generated the scaffolds, but it left a bad taste.

Granted, these are somewhat minor issues. Compared to writing something like this without Grails and Groovy, we’re still orders and orders of magnitude more productive. And since Grails is still so immature, it seems reasonable that these are things that will disappear as it gets more polished.

The Verdict

Graeme Rocher, The Man with The Plan when it comes to Grails, had this to say regarding release 0.4.2:

It is being used in production sites now and is built on such production ready frameworks like Spring & Hibernate. The main areas for improvement with Grails now are the developer experience.

However, as John Wells points out in his blog, there seems to be a dearth of information about sites that are really, actually using Grails for anything more than “CRUD ZOMG LOOK HOW EASY IT IS”. This is probably due to the fact that Grails is so young. I imagine that many people are trying it out, getting used to it, but holding off in developing real projects in it until it’s a little more mature. And given the experiences I had just playing around with a small demo app, I would say that people are right to hold off.

Grails seems to still be in its infancy. As it matures, it will likely develop into a powerful development framework that will allow you to do in minutes what it used to take you days to do. Granted, this is already possible in other environments, but not with that oh-so-holy grail (aha, the double meaning of the name becomes apparent) of using all the stuff you’ve already written in Java. Grails has an awful lot of potential, but it’s not quite there yet. For now, you’re better off getting your feet wet in something like Ruby on Rails, which is much more mature and will teach you all the concepts you’ll need to know for when Grails finally grows up.

This entry was posted on Wednesday, April 11th, 2007 at 10:04 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.