Deep Dive Underway: Rails vs Grails vs Play vs Zend
SOTA has two greenfield opportunities in play, both of which are mobile-first -> cloud and also involve domain model and persistence. To meet the requirements of these two new projects, I’m currently in a deep dive to evaluate four modern web frameworks:
- Grails (Groovy)
- Rails (Ruby)
- Play (Scala)
- Zend Framework (PHP)
I’ve read tons of information about these on the web, but I’m going to take the time to install all of them and do some experiments to see how well they support model-driven development, and moreover, to see whether I can stomach working with them.
Thus far I’ve spent most of my time with Grails, and I have to say that my initial impressions are good. This framework allows you to easily construct a domain model that is implicitly persistent in the database of your choosing, including NoSQL databases such as MongoDB. Once you do this, you can immediately begin to create controllers in Groovy that operate upon the domain model objects.
Under the covers, this system uses Spring and Hibernate, which for me are well known. The other thing that is very cool is how Groovy essentially modernizes Java. Most Java programs are also valid Groovy programs, but to take advantage of Groovy language features, such as closures and dynamic typing, you need to tweak your coding style.
Groovy classes are regular Java bytecode, so to get familiar with what is really happening, I’ve been decompiling the classes with JD (Java Decompiler). There are a lot of “secret” methods that Groovy creates in the bytecode that are the key to Groovy’s magic. The JVM of course is oblivious about whether the classes were actual Java or Groovy, which is one of the most exciting points about the Grails system.
Interoperability between Groovy and Java is seamless, and this is coming from someone that hates that word because it is usually baloney. In this case, it is accurate. In Groovy you can directly call on the jaw-dropping variety of open source Java code. There is nothing that you need to do that hasn’t already been written in Java at least twice.
Add to this spectacular tooling: The Groovy/Grails IDE (GGTS) is really Eclipse with some specialized plug-ins that leverage the Eclipse JDT (Java Development Tooling) package. This means GGTS is industrial strength and has everything needed for Grails iterative development in Groovy, Java or a combination of the two.
Based on searches of Monster and Google Trends, Grails penetration isn’t nearly as high as Rails (Ruby), but it can be considered on a low-burn upward trajectory. I can definitely see Grails on the short list of enterprise shops that have investments in Java, because it provides a viable solution for modernizing into the cloud. Being a seasoned Eclipse/Spring/Hibernate/Java developer, I take to Grails like a duck to water.
For shops considering Grails but concerned about the availability of Grails engineers, I believe a disciplined Java developer can be “retooled” for Groovy/Grails in short order, perhaps a couple of weeks. Thus, a Grails project can tap into a very large body of engineers, many of which will be highly motivated for the opportunity to work with this modern platform.
Grails is aligned with the Spring, Hibernate, Groovy and OSGi communities, and is loosely affiliated with the Eclipse community as well. Forgive me if I seem xenophobic, but this community is my “tribe” and that makes me instinctively lean towards Grails. Moreover, the company that I was contracting with last did a thorough evaluation of web frameworks over a year-long evaluation period, and ultimately chose Grails for their cloud migration efforts.
Grails reminds me of a battle-hardened aircraft carrier group. It is large, well-documented, industrial strength, ready for enterprise-scale projects.
