Graeme has published his 10 reasons to switch from Rails to Grails. I think his case is overstated, but that doesn't mean there aren't some good reasons. To clarify, I have broken his list into three groups: reasons to switch, edge cases, and crap.
1. Reasons to switch from Rails to Grails
These are real issues in Rails applications we have built.
- A view technology that doesn't suck. Rails offers a large variety of view technologies, but as I am not totally satisfied with any of them I could see spending time with Grails on this one.
- Built in support for rich conversations with Web Flow.
- A Service layer with automatic transaction demarcation and support for scopes.
2. Edge Cases
These aren't issues for me, but they are important to some people.
- Mixed source development made easy with the Groovy joint compiler. JRuby is enough for me, but YMMV.
- IntelliJ's JetGroovy Plug-in. I am happy with TextMate for now, but if you are an IDE type check out NetBeans (start with Tor's blog).
- A rich plug-in system that integrates Grails with technologies Java people care about like GWT, DWR, JMS etc. If you think it is hard to build a plugin system you are probably still having flashbacks to your bondage and discipline language.
3. Crap
Puh-leeze:
- Grails 1.0 coming out within the month. Sorry, but "we've never shipped and when we do we'll only be three major releases behind" doesn't motivate me much.
- Built on Spring, the ultimate Enterprise Application Integration technology. In other words, "We have one foot in the past, and leaky abstractions around every corner."
- A buzzing and growing community with a larger traffic mailing list as opposed to a stagnating one. Graeme, I double dare you to say this with a straight face.
- More books coming and being adopted by enterprise. I am a reviewer on some of these books, and they are good. But again, this is "Look--We're second-best and trying hard!" argument.
As a final note: One of the items above rightly deserves to be controversial, and represents the real, enduring difference between Rails and Grails. I think your opinion on that one item should drive most Rails/Grails adoption decisions. Can you spot it?
Comments
I would say that “A Service layer with automatic transaction demarcation and support for scopes.” is big issue. Rails needs better transaction support.
As for “A view technology that doesn’t suck. Rails offers a large variety of view technologies, but as I am not totally satisfied with any of them I could see spending time with Grails on this one.” What is about Rails view technology that sucks, and how does Grails offer something better? Rails rhtml + helpers seems to be the same thing as Grails GSP + tags, what am I missing?
Also, I agree, Graeme’s post totally says to me “Hey, pay attention to my framework!”. If it is truly better, point out specific difference in a blog entry each, people will read that and determine for themselves. Saying “The view technology of Rails sucks” doesn’t convince me of anything.
One more thing, you need a bigger textarea for comments on this blog :)
Doubt it’s the one you meant, but I HATE jsp/cold-fusion style faux-tag templating, so the very first one is controversial for me. ;)
For me that one thing would be a combination of two of the bullet points – mixed source and Spring. The choice would come down to whether I wanted or needed to leverage existing Java/Spring code, and/or had a team of most Java developers new to dynamic languages.
For me, it is the “built on Spring” claim. Spring is successful only because it was a patch for J2EE’s bugs. The fact that “Enterprise Application Integration” is all capitalized illustrates the mental model of each camp. Rails’ mantra is development that doesn’t hurt and stays clear of “enterprisey” qualities intentionally. Grails openly embraces some very painful technology and actually does a very good job of simplifying said technologies.