First Impressions from Groovy and Grails

Well, I took upon myself the task of learning a new web application framework for a small personal project I’m working on. Honestly, this is somewhat new to me. Aside from a short one-night-stand with an organizational J2EE framework[1] as part of my training a couple of years ago, I never had anything to do with GUI or business application development. I was quite excited about the possibility to learn a new language, new tools, new ways of thinking and gain experience with a new type of missions, and I happily set out to see what’s out there.

After a short exploration, I decided to play with Grails (aka. Groovy on Rails) for several reasons:

  • Groovy is written for the JVM, and uses most of Java’s features and syntax, which allows for a smooth entry and fast productivity for a Java developer like me.
  • I’m under the impression that being able to seamlessly integrate several languages over the same runtime is a good thing. I think that every language has it’s advantages. Java is working well, is simple and familiar, and most importantly – gets the job done. Groovy seems like it’s good choice for a scripting language for the JVM, and Clojure[2] seems like a good option when complex calculations are called for.
  • Grails is built upon Hibernate and Spring, which are two frameworks that are widely used in the industry and that I have good, albeit limited experience with. I’ve been meaning to learn more about them for a while now, and well – here’s the chance!
  • Should be faster than other similar frameworks.

Well, having my exams to study for and my daily job, I didn’t have too much time to play with my new toy, but I already have several things to say[3].

While Grails has several IDE integrations, I chose to use Springsource’s STS, which is an Eclipse-based IDE as a development environment. I didn’t take me long to realize it might have been a mistake. Aside from the fact that IDE itself is heavy and slow on my machine, running Grails related commands, and have no mistake – you need to run many during the course of development, requires loading the Grails runtime, which is a slow-slow process. Having to wait several minutes for the simplest of actions to complete really ruins the working flow, and you know how much I like that.
In Grails defense I will say that my computer is almost 5 years old, and that eclipse wasn’t the best IDE choice to begin with.

So far it seems like Groovy is the down-side of this bargain for me. Of course, I’m not well versed in the language yet and I assume things will seem more natural to me as I learn more, but after reading a good deal of the getting started guide (and especially the style guide for Java programmers), I am a bit disgusted. Yes – I admit it, I am highly fond of rigid formalism and I have a slight mistrust in dynamically typed languages as a result, but this is not the issue. Right now the Groovy seems to me like a collection of random features and syntactic constructs that were plundered from other languages and forced to live together without harmony.
I don’t like the fact that there are several ways to write the same code. I don’t like the fact that return statements, parentheses and semicolons can be sometimes omitted[4]. I don’t like the ways methods were added to the JDK, which breaks any form of reasonable design.
Well, you catch my drift.

If you don’t look too hard at the Groovy code, the Grails framework was surprisingly easy and fun to get started and work with. The project is very well structured, everything has its place, most – if not all – the things that you need to do beside pure business logic have already been thought of, and everything is designed to promote good programming practices.
Of course, a good framework is really put to the test when you try to use it in ways that stretch the limits its original designers had imagined for it but I didn’t hit that spot yet so I really can’t tell.

I did have one problem with the framework, from a newcomer’s point of view. Its design relies heavily on the convention over configuration principle, which helps keep the project very clean and the development fast-paced when you know what you are doing, but it really makes it hard for me to learn how things work. When I face a new technology, one of my preferred methods of learning is by “pulling out threads” of software – I find something that I don’t understand, like a piece of code or configuration, and I follow its lead by searching strings in the project sources, configuration or compiled code, decompiling classes where necessary, until I reach some code that I do know.
I like this method because it really helps understand the “guts” of the technology or project you are working with, but with CoC, you have to know the convention to be able to follow the thread, which means that in order to learn I have to… know in advance what I’m looking for?

These are my thoughts on the subject for now. I’m sure they will change over time as I’m still green around the edges[5].


[1] Which, admittedly, was quite advanced for its time
[2] Which will probably be the next language I will try to put to practical use
[3] This statement shouldn’t surprise those who know me, and the fact that the real challenge with me is to make me SHUT THE F#@& UP!
[4] And sometimes not?! They make things formal, dammit!
[5] Pun intended

Advertisements

1 thought on “First Impressions from Groovy and Grails”

  1. While I love the platform and the eclipse based IDE, the time it takes to do any of the grails command really is annoying. Django and rails are much much faster.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s