There are quite a few modern web frameworks out there vying for attention. In the startup scene, where CTOs have carte blanche, frameworks like Rails (Ruby), Django (Python), and CodeIgniter (PHP) seem to get the most attention. All of these frameworks are highly productive in a green field environment. In an enterprise setting however, Grails has some compelling advantages over these frameworks, making it a natural choice for any enterprise IT shop seeking the extreme productivity that modern web frameworks offer, and that startups take for granted.

First, let’s talk about productivity. Grails is every bit as productive as any other modern framework, if not more so. Having built apps in both Grails and Rails, I can honestly say that in my opinion Groovy as a language and Grails have a framework have both improved incrementally on the productivity of Ruby and Rails. I’ve found that the ability to type variables when you need to in Groovy can make a huge difference in the kinds of features that a framework can offer (like model classes that actually look like model classes). As for Grails, automatic schema generation without having to even think about database structure (yet) makes getting started much easier than it is with Rails.

So, if Grails offers such great productivity, what’s holding its adoption back in the startup space? Ironically, the same features that make Grails such a natural choice for the enterprise are part of the reason for it’s relative lack of adoption in a green field setting compared to other popular frameworks – but that’s a topic for another day.

For now, let’s take a look at why Grails is such a natural fit in an enterprise setting.

The JVM

Grails is based on the Groovy language, which runs on the Java Virtual Machine. The JVM has been around for an eternity in technology terms, which means a few things. First, it’s been actively improved for over a decade. The result is what many consider to be the best run-time environment available. Features like just-in-time compilation and hot spot optimization have allowed it to deliver about the same speed and reliability as C++ – no small feat. But more importantly for an enterprise shop, it means that there are literally thousands of tools on the market that integrate with it. Just about every enterprise-grade monitoring solution, for example, has some ability to plug into the JVM (typically via JMX) to monitor any run-time metric that you’ll ever need.

From a developer’s perspective it also means that you have native access to every Java library out there – and there are many. In an enterprise setting, it may be a Java SDK provided by a legacy product, or a third-party vendor. Because of Java’s broad penetration, it’s typically the first (if not only) language that vendors target when releasing an SDK. Aside from vendor SDKs, there’s the massive amount of open source libraries available – Apache Software Foundation anyone? Again, because Java is so widely used and has been around for so long, just about every problem that a developer can face has been solved at least twice in Java. This is especially true for “enterprise-y” type problems since Java is used in so many enterprises.

Groovy’s flat learning curve

Groovy was specifically designed to be easy for existing Java developers to pick up, and it achieves that goal in spades. Groovy’s syntax is backwards compatible with Java, which means that a Java developer can write Groovy code with zero investment in actually learning Groovy. Of course, this isn’t a valid long-term approach as simply writing Java code in Groovy doesn’t provide any of the massive productivity gains that Groovy delivers over Java. It does, however, make Groovy the most approachable dynamic language for a Java developer hands down. Since most enterprises will already have teams of Java developers on the ground, this makes a huge difference in how much investment is required to make the leap to a highly productive framework like Grails.

Groovy is also based on the JDK, leveraging and extending the core Java APIs that are burned into every Java developer’s brain. This means that a Java developer coming to Groovy doesn’t have to re-learn the basics. A String in Groovy is an instance of java.lang.String. A List in groovy is an instance of java.util.ArrayList. All of the JDK’s classes and methods are accessible, and some highly productive extensions have been added as well in the Groovy Developer’s Kit.

Based on well known, enterprise-y, core technologies

Instead of reinventing the wheel, Grails leverages two mature, proven core technologies – Spring and Hibernate. Given that the majority of enterprise Java shops already have an investment in Spring and Hibernate (the de-facto standard Java framework stack), this lessens the learning curve for Grails even further. That’s not to say that deep Spring and Hibernate knowledge is required, since Grails does a great job of shielding developers from the underlying Spring and Hibernate APIs, but it’s definitely helpful in dealing with the edge cases that you typically find in an enterprise setting.

Being based on Spring and Hibernate also means that there’s a huge knowledge base in the ether on solving issues common in an enterprise environment, where these technologies typically find themselves. Need to know how to map a Grails domain class to a stored procedure? Because Grails is based on Hibernate, you can leverage the experience of the Hibernate community and find dozens of helpful examples. It’s then just a simple matter of applying that knowledge in Grails, which typically means using a Domain Specific Language for configuration instead of overly verbose XML files.

Leverages existing operations knowledge base

In startups, developers typically wear every hat in the IT org, context switching from developer, to dev ops, to sys admin at least a few times a day. In an enterprise setting, developers thank their dedicated operations teams every chance they get for taking all of the dirty work of keeping things running off their hands, allowing them to focus exclusively on building apps. In doing so, the operations team inevitably builds expertise in dealing the the JVM. They instinctively know what -Xms and -Xmx do, and they know how to tweak the JVM’s perm gen size to stop those nasty OutOfMemory exceptions. Again, because Grails is based on Groovy and the JVM, all of this knowledge is on tap for Grails apps.

Leverages existing Java middleware

Any enterprise shop with a Java presence will more than likely have at least one (if not a few) Java application servers in production. There’s commercial app servers like those from big red and big blue, and of course the open-source equivalent Tomcat. Thanks to Grails’ Spring underpinnings, a Grails app looks exactly the same as any other Java EE based app from a deployment perspective. Deploying a Grails app generates a .war file that can be dropped into any existing app server. In an enterprise with a huge existing app server footprint (perhaps in the 100s or 1000s) this is a huge deal, and means the difference between leveraging a massive investment and throwing it away and starting over.

Thinking again of our friends in operations, this also means leveraging their existing expertise again when it comes to tuning the app server of choice. An investment, for example, in a robust set of Jython scripts that configure and deploy Java apps to WebLogic clusters can be leveraged as is for Grails apps.

Huge labor market

Finally, there’s the massive labor market for Grails development. “But wait”, I hear you saying, “how many Grails developers are really out there?” Wrong question. You’re not hiring Grails developers, you’re hiring Java/Spring/Hibernate developers. Any Java developer worth his salt can be productive in Grails in a few days, and can be very dangerous (in a good way!) in a few weeks. So, don’t waste your time searching for developers with Grails experience. The right question is, how many Java developers with Spring and Hibernate experience are there? More than you’ll ever need.

It’s only a matter of time

Grails has been around for a while now, and it shows no signs of withering away as some predicted several years ago. In fact, Grails 2.0 was recently released, and it’s clear that Spring Source is committed to continuing to fund the development of Groovy and Grails. We’ve also seen a number of cloud hosting providers like Heroku and Cloud Foundry add support for Grails – another measure of its adoption and staying power. As Grails continues to mature, and enterprise IT shops struggle to keep up with the rapidly increasing pace of innovation, it’s only a matter of time before they start adopting Grails en-masse. For a Java shop, it just makes no sense to adopt a brand new stack like Ruby on Rails and throw away their massive investment in skills, operational knowledge, and middleware.

If you’re in a Java shop that’s struggling to keep up with your business, now’s the time to push the Grails agenda.