At the end of this post I will tell you whether to use Rails or Grails for web development. But first, let me tell a tale of two decision makers:
- Joe has a problem to solve. The problem is specific, the need is immediate, and the scope is well-contrained.
- Jane has a problem to solve. The problem is poorly understood, the need is ongoing, and the scope is ambiguous.
How should Joe and Jane think differently about software platforms?
- Joe's platform needs to be mainstream. It needs to offer immediate productivity, and the toolset should closely match the problem. Also, Joe doesn't want to climb a learning curve.
- Jane's needs are quite the opposite. Jane needs flexibility. She needs glue that doesn't set. She needs a way to control technical debt (Joe doesn't care.)
For my part, I am interested in Jane's problems. (And anyway, Joe often discovers he is actually Jane midway through projects.)
So how does this affect platform choice? If you are Joe, you care about specific details about what a toolset can do right now. Most of Graeme's Top 10 reasons are in the "Right here, right now" category. This is true regardless of whether you think he is right. (Sometimes he is, sometimes not.)
My advice to Joe: Know exactly what you need, and then pick the platform that comes closest to solving it out of the box. Depending on Joe's needs, either Rails or Grails might be appropriate (or neither!). A particular point in Grails' favor would be an established team of Spring ninjas.
If you are Jane, you care more about architecture. I mean this term in two senses:
- Architecture: the decisions you cannot unmake easily.
- Architecture: the constraints on how you think and work.
If you are Jane, you care about how and why the platform was assembled, because you are likely to have to adapt it quite a bit.
Most of the commenters on my earlier post (and Graeme in his addendum) correctly identified the real architectural difference between Grails and Rails. Rails builds on Ruby, while Grails builds on Groovy and Spring. Rails wins this architecture bakeoff twice:
- Ruby is a better language than Groovy.
- Spring does most of its heavy lifting in the stable layer, which is not the right place.
My advice to Jane: Rails over Grails.
Comments
I really can’t even make sense of this post. Spring is my favorite technology for dealing with technical debt. In my experience, it enables building systems out of components that 1) are testable outside of app server and 2) not tightly coupled. As bonus, 18 months after using Spring as factory for my objects, I find I was able to easily inject special common error recovery behavior into all of my unrelated components with Spring AOP.
Scott: Everything you say is true. Spring is the most established way to solve issues of testability and tight coupling in the stable layer. But these problems are caused by trying to do too much in the stable layer to begin with. We too have had good success using Spring as a palliative, but at this point I am more interested in a cure.
Scott, Spring solves problems you don’t even have with more dynamic languages. Back in my Java days I also was a fan of Spring, but since then I didn’t miss it when doing Rails projects.
Thanks to duck typing, meta programming and open classes that can be changed from anywhere in your code, anytime, you don’t need special AOP libs if you have your whole application written in Ruby. Just override the method in question, apply any before/after stuff you want to attach to it, and you’re done. Plus this can be easily done on single Objects, at runtime.
And yes, Rails’ test suites also run outside the ‘app server’. And there’s plenty of support for mock objects and friends to help you test your components.