Software Journal

I have recently been inundated by emails about Grails (mostly good, some neutral, some outright complaints), even though my email inbox isn’t much different from a certified black-hole. The great divide seems to be part philosophical and part technical. There are already quite a few technical comparisons of Grails vs. Java/Struts out there, such as: CompleteOpenSource, Nabble and StackOverflow, not to mention the big comparison over at JavaOne, but some of the philosophical issues seem harder to tackle:

1. Unsubstantiated Claim #1: Hesitation to move to Grails is really an unwillingness to learn anything new on part of Java developers.
   Really? This is a subjective claim, and I am sure it is going to be neither true nor false. But my personal experience on this issue suggests that Java developers do not want to learn Grails simply because they want to focus on solving new problems, not focus on solving new problems in a new way! It is the “new problem” that is of interest to them, not the “new way”. One could argue that “new way” can make things much faster for them, but the Java developers frequently argue back that business (and not technical) problems are the ones where they are spending the time, so the “new way” isn’t likely to change much in that case. This represents an implicit high level of maturity in Java/Struts based enterprise systems.
2. Claim #2: Grails is easier for development.
   Java, since its day one, has been known to be harder for development than say VB. Still, that has not stopped Java from progressing and reach dizzying heights. So, what does that teach us?The language/framework needs to be easy to develop, and scalable/efficient to execute/deploy. Which of these two attributes is more important – that is an inane question. Can you turn one knob up and the other knob down, and come out better? I don’t know.With Java/Struts, apparently, the difficulty in development was not a show stopper. If Grails promises to ease development, but is even an epsilon less scalable, that already makes it a partially ordered set. In fancy terms: Grails, in that case, is not a Pareto optimization over Java. In layperson’s terms: win some, lose some.
3. Claim #3: Grails doesn’t have the same security of compile time checks.
   The bad news is that for a production system, this isn’t so good. The good news is that by integrating unit tests, the impact of this problem can be minimized.
4. True, but pointless Claim #4: Convention over Configurability.
   This one is surprising. Grails lovers claim CoC to be a big plus. Java developers don’t see why this should be a reason for celebration at all. Configuring a project takes very little time these days, and if you do that, and retain the choice of configurability, then should you be interested in something that takes 10 less minutes to setup, but is not as configurable?

Obviously enough, jury, is still out on this one.