I just wrapped up the majority of the development on a Grails application. This was my first experience using Grails and Groovy and I must say it was a very pleasant experience. It was very similar to the experience I had with Rails a couple years back, except that I ran into a lot fewer glitches. The installation of Grails was simply unzipping a .tar file and setting up a couple of environment variables. My Rails pre-1.0 experience was filled with grabbing specific versions of libraries and compiling them with specific options, ugh. I’m sure things are much better in Rails land these days, and I hope I get the opportunity to work on another Rails project to see how things have progressed, so if I make any erroneous comparisons to Rails, I apologize.
Back to Grails. It had the standard scaffolding to start a project and create the initial data models, controllers, and views. One thing that was different from Rails was the lack of database initialization and migration. Any model changes would be reflected in the database the next time the application was started. I’m not sure how I feel about this. It was nice that I was insulated from the changes, but when I made changes and wanted to keep an existing database I ran into problems if the new column was not NULL or if I had to change the uniqueness. Maybe there is a mechanism that handles this, but it wasn’t part of the tutorials I went through like migrations were in the basic Rails tutorials.
One of the most comforting things about Grails was the ability to use any Java libraries. In this case, I needed a library to access Twitter and of course there was one. I’m sure Python, Ruby, et al. have Twitter libraries, but before I settled on Grails for this project, I was a little concerned with what the state of any Twitter libraries might be.
I’d also like to comment on Groovy the dynamic language that forms the basis of Grails. Part of Groovy’s strength is that you can write Java code and it is valid Groovy code. For me, it was actually disconcerting to be able to write Java code. The problem is that I like to be idiomatic, so if I’m writing Groovy code, I want to write good Groovy code. The fact that I could throw in some code that looked like Java had me concerned that I wasn’t using Groovy like a Groovy programmer.
In conclusion, it was a lot of fun developing a non-Struts web app and while I have plenty to learn about Grails and Groovy, it was easy to very productive which is what I want from a framework.
