Yes, I know it's Lent, but I'm not talking about that Grail - I'm talking about Grails, the web framework for Groovy (the dynamic layer for Java).
I've been looking for a way to ditch CFML for a while now, but nothing has really hit the mark. I keep hoping that Adobe is going to release CF8.1 with Flex 3 and allow all your server-side scripting to be in ActionScript 3, but I'm not holding my breath. The CF platform is pretty nice (excepting the massive bloat), but the CFML language itself just blows ass. So I shop…
I liked SpringMVC/Spring/Hibernate when I was using it, but it's definitely enterprise-y. I've looked at Rails, but I really dislike Ruby's syntax, and ActiveRecord leaves something to be desired (like a query language). Django and Pylons (for Python) are slick seeming, but Python's whitespace-is-semantic paradigm is a big turnoff. My CFRhino "project" actually has some promise, I think, but not something I want to get into maintaining for real application development, and it's JavaScript, which means no real classes and classloading (among other things).
Enter Grails. Like it's counterparts in other languages, it's all about speed of development, but unlike the others, it's all Java. It's built on Hibernate, Spring, and SpringMVC. It compiles to bytecode. It seamlessly integrates with existing Java apps and tools (Quartz, Acegi, DWR, etc.). The paradigms it leverages were incredibly easy to jump into (granted, I've used it's backing tools before), and within a couple hours of seeing both Grails and Groovy for the first time, I had a quasi-functional blog platform.
The past week of developing a first "real" app has borne out my initial impressions to the nth degree. Groovy is a really slick layer that augments Java in just the right ways, without getting the way. Closure are a big deal, vastly superior to simple functions or Java's inner classes. You also get dynamic methods, iterators, native regular expressions, multi-line strings, ranges, a ternary operator (c'mon CF, it's not the 60's), the "elvis" operator which is the ternary operator with the middle clause omitted and the first clause used as it's value, and null-safe dot operator.
But Grails is where it's at.
class User {
String username
String password
String email
static constraints = {
username(blank: false, unique: true, size: 4..16)
password(blank: false, password: true, size: 4..32)
email(email: true, blank: false)
}
}
That whopping 11 lines of code is sufficient to create a domain entity with three fields, create validation for the fields, create a Hibernate mapping, and set up all the SpringMVC goodies for binding, form generation/population, error messages, etc.
Request processing, you ask? You have a collection of controllers (think circuits, if you know Fusebox), each of which is a collection of actions (i.e. named closures) corresponding to requests (think fuseactions). So the URL "/login/doLogout" would map to the "doLogout" closure of the "login" controller. Each action closer can redirect, render directly, or return an arbitrary data structre to be passed to a view. By default, the view is a file named to match the action, in a folder to match the controller (you can override, of course), which is written in Groovy Server Pages (GSP). Think JSP, except without the heavy dose of suck. For example, you can define taglibs using Groovy, and then use them in both your views and your controllers, as either tags or as functions.
Grails (thanks to Spring) also provides all-encompassing dependency injection for not only your services and controllers, but for your domain objects as well, which is fantastic. That was one of the larger problems I had with using Spring and Hibernate directly, and one that I never was able to solve in a very satisfactory way. It also provides controller filters which are exceptionally handy (enforcing logins, adding model data for your layouts, etc.).
And the last big piece is SiteMesh, which is the [optional] layout toolkit. You can certainly use GSP for everything; simply include your header/footer as needed and go. But SiteMesh provides basic page wrapping functionality to ease the task, along with a very powerful content dissection/assembly framework (think Fusebox's contentvariables, except managed by the view as they should be).
Finally, yes, there is pretty comprehensive scaffolding support. It doesn't blow my skirt up as much as the other stuff though, but that's probably more a reflection on the type of apps I'm usually building rather than the general utility of the feature.
In case you can't tell, I'm impressed. The Grails guys have done a fantastic job at taking some incredibly flexible and powerful tools and making them ridiculously easy to use.
Great post. After my first look at Grails I thought it was so similar to Rails that I didn't need to look further in. This post, coupled with Sean Corfield's two recent posts about Groovy and Grails has made me rethink that position.
I'll be digging deeper into it at some point.
Barney, thanks for the comprehensive post GRAILS-GROOVY certainly seem worthy of a closer look and I will do so, time permitting. Do you have any thoughts on how easy or hard debugging is? I spend much of my time troubleshooting and fixing applications and ColdFusion has always had great debugging information?
Mike,
Since Grails is all Java-backed, you can use all your standard Java tools (e.g. Eclipse debugger) to debug your apps. The runtime error template is part of your project (generated for you, of course), so you can customize to your heart's content which is handy as well.
More important, I think, is that you get far better tool support with Groovy/Grails. That lets you catch a lot of potential errors in the IDE rather than at runtime, especially if you leverage static typing where appropriate. Regardless of how good the debugging tools are, not having to do it at all is always better.
Thank you sir.
This is just what the doctor ordered. I had a similar experience with rails and python. Java is great but it has a huge learning curve and I am still very much a beginner. But I was able to dig right in with Grails and felt comfortable right off the bat.
Having support for Eclipse and Netbeans is huge.
Interesting to see you post such a glowing review of Grails after I'd posted two similarly enthusiastic pieces. I only investigated it because of a comment by Dave Ross - after Derek Perez had been bugging me about Groovy. Coincidence or critical mass? :)
Sean,
I'm not going to call it either way, but Grails definitely provides a lot of stuff that a certain set of CF developers have been crying out for, and does it without requiring as large a shift as other alternatives. I haven't done it, but I see no reason that you couldn't easily build a hybrid CF/Groovy/Grails app, and with enormously less pain than CF/Java hybrids.
I know I'm going to be doing CF for a good while since Mentor's heavily entrenched. CF's relevance is definitely waning (regardless of Adobe's sales figures). Perhaps an influx of good ideas could buoy it.
I hate to drag out a discussion Barney but why do you believe that CF's relevance is waning? This is a genuine question because from my end of things in the server tuning business I see large entities that were not CF users needing help. Also I don't see any of the associated companies pulling back or financially in trouble (New Atlanta for instance). None of the companies which were spawned from the Macromedia Consulting division have gone. Webapper, Universal Mind etc, in fact Universal Mind were recently listed in the Fortune 500.
I have no doubt that Groovy and/on Grails is an exciting track to go down but I am not sure that relates to CF being less relevant; just my opinion from indicators that I see. Thanks again.
Mike,
Eight years ago, CF was awesome. It blew the pants off other languages available for developing web apps quickly and easily. These days, it's a far less compelling choice. I doubt it's market share has diminished, but I feel that it's relevance has.
I wasn't referring specifically to Grails as the reason for it; I've had that opinion for quite a while. There are a whole pile of web toolkits out there now, and they're breaking some cool new ground. I wouldn't care to use a number of them, but I do appreciate what they're doing. CF, on the other hand, has done little. CFC's were a step in the right direction, but the implementation is poor in many ways. Other than that, almost all improvements have just been reinventing the wheel with CFML syntax, and often in a very limited way (consider the mess that is CFTHREAD, or the breaking of CFMAIL when CFMAILPARAM was added).
I just wanted to comment on something you said about Rails ActiveRecord. Like you, I've switched away from CF for a variety of reasons; unlike you, I'm currently using Rails, and I very much like Ruby's syntax — it's certainly different from a lot of other languages, but I think it's extremely well designed.
Anyway, you said that ActiveRecord doesn't have a query language. If I understand correctly what you're getting at, that's not quite true, at least in the sense that you can pass native SQL code to ActiveRecord.find_by_sql . There's certainly nothing in Rails like EJBQL, but to my mind that's OK — who needs to learn yet another dialect of SQL?
How does Groovy deal with this? I've never worked with it, although my last job was with a company that created what as far as they knew was the largest Groovy project to date. But I wasn't working on that project.
Marnen,
Groovy doesn't have any sort of ORM framework itself, though it does have a slick-seeming SQL interface. I haven't actually used it, so I can't say for sure though.
Grails uses Hibernate under the hood, so you have access to the full Hibernate stack, including HQL. I suppose picking up the dialect is a bit of work, but it's never been an issue for me, even when starting. More troubling is thinking in terms of querying objects, rather than tables. That's a conceptual hurdle that took me a while to get my head around (and I still sometimes butt up against). However it does allow a far more business-model-centric way of querying which is quite nice, as well as providing an abstraction layer that allows you to extend the query language in an application-specific (and DB neutral) way.
When I said ActiveRecord didn't have a query language, I was referring specifically to querying the conceptual object store to select instances. find_by_sql doesn't even come close to that: it's nothing more than a way to do raw SQL queries against the DB connection configured for ActiveRecord. It's really more analogous to getting a Connection object from Hibernate and doing SQL against it (using Groovy's SQL stuff, or plain JDBC).