"Griffin, great and growing"

That is (or was) the wording on the water tower for the humble town of Griffin, GA, U.S. of A. I once had a colleague who lived there, and he mentioned that quote with a wry smile. I almost want to say "Grails, great and growing." I've been playing around with Grails now for a few weeks. Unfortunately due to my work commitments, I tend to have sporadic spurts of play, but I'm getting more and more used to it with each session.

Clearly a lot of work has gone into Grails. Chatting on-line to Graeme Rocher, the Grails project lead, I learned that he has an hour to kill on the train from Brighton to London and back - that's an hour there, and an hour back - hence he has time to work on Grails. Time well spent by the looks of it. At v0.4.2. Grails is already quite complete in terms of the architecture and the basic components that you need in a web development framework. What I like most about Grails is that underneath, you're running Java, and Grails uses proven Java libraries like Spring, Hibernate, and Sitemesh. The fact that you mix in a bit of Groovy to glue it all together is a wonderful compromise between productivity and scalability.

I think that's what bothered me about Ruby on Rails. Productivity is great, but at the end of the day, you're still running Ruby, and underneath it all, it's Ruby, and the web server that you use for Rails is essentially single-threaded. Now, before this starts a flame war, I have read about how Rails developers accommodate this to accomplish scalability, so I have to take their word for it that it accomplishes their desired levels of performance. However, to a hardened Java developer like myself, the fact that you're effectively running Java when you're running Grails is a distinct benefit. If I haven't said it eloquently enough, I think Graeme Rocher himself said it best in this entry on his blog.


I think I liked the following quote from that entry best:

Dynamic languages are only useful for small to medium complex applications. This is also "fact". Having supported a multi-tier Perl system for a number of years I would rather die than have to write a complex banking system completely in Groovy or Ruby. But, I would be quite happy to write parts of it in either. If you take this approach you get what I call scalable complexity. The ability to start off in a dynamic language and when things get tricky implement certain parts in Java.

That hits the nail on the head in terms of what I was trying to explain earlier. "Scalable complexity" - Graeme, hope you don't mind if I use that in a meeting somewhere to build up my Dilbert points. ;-)

What's interesting in this debate is the clear sides forming within Javaland on the merits of adding effort to Groovy or of shoehorning JRuby into the mix instead. Personally, there's no debate. As Graeme points out, if you read that entire entry, if you're dealing with Groovy, you're dealing with Java. If you're dealing with JRuby, you're dealing with Ruby, with it's own of (different) threading model, I/O, API etc. So you're going to have to be familiar with both Java and Ruby. With Groovy, you're only dealing with Java. Considering Groovy is equally effective and productive, it is hard to understand why Sun are trying so hard to undermine their own language.

As I've indicated previously I've long felt Java technology suffers from really bad marketing. Often the concepts are great, but the name alone prevents you from daring to put a book about it on your shelf, for fear of being shunned like the lepers of old. No offense, but Groovy is a really horrible name for a technology that wants to be taken seriously. Perhaps that's something that the Groovy stakeholders should consider changing. Perhaps that's why Sun are too scared to strap themselves to that wagon. Of course, I don't really consider myself a marketing type, so I won't attempt to offer an alternative. I do know names like "C#", "C++", "Perl" and "Delphi", for instance, can be talked about without the need for copious blushing, or girly snickering under the table at each mention of the name. What's in a name? Maybe more than we really think. What do you think?

Choice is good, too much choice is bewildering

Ever been to a restaurant that has a 30 page menu, and you have one hell of a job trying to decide what to eat? I have. It's very bewildering. I like choice. Give me a choice between fillet, rump and sirloin, and I'm okay with that. But give me a list of 40 pizzas and I have a dizzy spell.

Now take that a step further, where you find a restaurant that you're really impressed with. You had their Chateau Briand and loved it the last time you were there. You walk in with your mates, sit down, and look for the Chateau Briand on their menu, and it's not there. So you ask the waiter:

"Erm, what happened to your Chateau Briand?"

Waiter: "Oh we don't offer that anymore, but now we have this really scrumptuous Carpet Bagger steak!"

You: "But I really liked the Chateau Briand, what was wrong with it?"

Waiter: "Oh nothing but the chef got tired of making that. He felt it was becoming passé and wasn't sexy enough anymore, so he stopped preparing that. But he's now really plugging his CarpetBagger steak!"

This morning I had a 'debate' online with a mate of mine, Chris Miller. He's an annoyingly smart developer who more often than not wins these little debates we have. I posit, he counter-posits, I counter-counter posit, and he slam-dunk posits, and then I end up sobbing in the corner. Okay, I digress. The point is I was bitching and moaning about the constantly changing landscape that is Java Web Frameworks. The huge proliferation of Yet Another Web Framework's that is out there in the Java web space. I haven't done Java web development for quite some time now, and recently have returned to the web space because of a personal project I want to explore. I refer you to my recent posts while hitching a ride on the Grails bandwagon.

The last time I did a Java web application, I chose Webwork v1.x as my preferred Java web framework. Webwork was a great framework. A very unimposing, yet powerful framework, true to the intelligence that is Rickard Öberg, the initial developer of Webwork, before it entered the OpenSymphony suite of frameworks. I enjoyed developing with Webwork as it allowed me to focus on the business features I was trying to implement without imposing any configuration distraction, or "square-peg-in-round-hole" forcing. There were a number of really smart individuals who had a hand in Webwork development, like Mike Cannon-Brookes, Hani Suleiman and Joseph Ottinger.

Then one day, a guy by the name of Patrick Lightbody had some or other epiphany and decided that Webwork needed a complete rewrite, basically, and he started on a journey that became Webwork 2. Development on Webwork 1 ceased. Hani made a valiant effort to try to migrate some new (and admittedly useful) functionality from Webwork 2, back to Webwork 1, but he had to work to pay for all that Mac machinery he owns, and so Webwork 1.x development basically ground to a halt. A year or two later and what do we have again? Oh look, Webwork 2 and Struts are merging to become Struts 2. Imagine my surprise. Why? What was wrong with Webwork 2? It's almost like these guys just get bored and decide to rewrite stuff.

Chris (Miller) argued with me that this was irrelevant. That there was nothing wrong with Webwork 1.x that should have caused me to have to upgrade to Webwork 2, other than if I was simply trying to remain 'trendy'. Now as somebody who doesn't get out much, 'trendy' isn't a moniker I would use for myself, and it's not something I attempt to accomplish. However, as I indicated, there were features which Webwork 2 had, which would have been useful in Webwork 1. Off the top of my head, I offered 'interceptors' to Chris, as an example. So you either stick with Webwork 1 and look enviously at all those using a better way to do what you're doing, or you upgrade (probably yet again!) or you enhance Webwork 1 yourself (which I'm not sure if I'm smart enough to do, and I don't have the time). Chris contended that despite the noise that exists in the Java landscape, it's usually easy enough to sift out the wheat from the chaff and if you just focus on the small handful of wheat, you can stick with one choice for a long time before you might have any need to do the upgrade dance. This is true, though often the most-used framework is not always the best framework. Struts 1.x is testament to that.

I guess for me, the issue is the sense that there are so many smart developers out there, giving of their intelligence and time, that it's a pity there isn't more cohesion amongst them. Is it ego's that clash? Disagreements that lead to feuds which lead to divergent frameworks? It seems like there's so much time wasted because of differences of opinion, that lead to reinventions of the wheel. These reinventions mean the rest of us who use these frameworks do a lot of tail-chasing.

I guess beggars can't be choosers, and if I'm not going to contribute in some meaningful way to these frameworks, then I can't complain. Put up or shut up. True, I can't argue with that. But from an objective perspective, it's still a pity. Take for example the Java workflow space. Here's a post from Carlos Perez's Manageability blog. Just look at that proliferation! I count 40, yes, 40, different Java workflow frameworks. I mean, surely there's enough commonality in the workflow space that we don't need 40 frameworks. Is it bad co-ordination? Poor communication? What is it?

Well I don't really know, but it's annoying, and it's a pity. And furthermore there's really precious little you can do about it. Open source is a voluntary beast, so you can hardly go around dictating to developers as to what they should do with their spare time.

If you've read any of my earlier posts you will have seen that I've jumped onto the Grails bandwagon. I just really hope and pray that Grails sustains the attention of the developer community sufficiently to remain relevant for a long long time. If not, it'll be a bit of a gamble since Grails applications, by their very nature, are significantly different to most other Java web frameworks, and web development methodologies.

Postscript: The one fairly important aspect I've completely omitted here is what we get from those who are somewhat at the reins in our industry. Consider, for example, Java Server Faces (JSF). I must admit to not having played with JSF at all. However, I can't say I've found a single positive comment on JSF by those not specifically biased due to their involvement in the JSF effort. The overwhelming consensus that I have picked up on is that people feel that JSF ignores what Java developers actually asked for. That it's delivery was grossly impotent when considering its potential and initial promise. EJB is another example. Look at EJB 1.x and 2.x. Yick! EJB3 seems to finally be getting somewhere close to what Java developers have wanted all along. So does this suggest part of the problem: that the leaders in the Java space are too introspective, and they don't actually listen to what their developer masses are asking for? How long did developers complain about the lack of exclusion patterns in the servlet specification? So perhaps our fearless leaders have some blame to bear in this mess that is the Java web framework landscape.