Tuesday at SpringOne2GX 2013 was chock full of content. The Grails BoF was by far my favorite session: no set topic, just a room full of devs, the Grails team and Groovy team reps, and a cart of beer.

This reaction to what was discussed is written from a largely outsider’s perspective: I’m still new to Grails, but I’ve spent a decade now leading other framework development, in BoFs, on advisory boards, and generally getting batted around by the suitwearing world as the often “token geek” in business meetings.

The same old situation.

What surprised me was a topic that came to the forefront: “How do we get the word out? We’ve got this great tool here that we feel should be universal, but a lot of the Java community even calls it a ‘toy.'”

“More tutorials/cookbooks, better marketing, more training,” and so on, called the crowd.

Dan Vega, Brian Kotek, and I all exchanged a look: this is what the Adobe development communities for Flex and ColdFusion said for years: before they largely died out.

ColdFusion’s long past its opportunity to evolve: even its “old guard” pokes fun at the new version’s irrelevance. Flex is a different sad story.

Grails, however, has its technical sh-t together.

A better ball and chain.

In contrast, Graeme Rocher put forth a vision for Grails that illustrates the advantage of being an open, community-driven project. Grails can pivot, turning ninety degrees from being a “Web framework,” leveraging a set of strengths not many may recognize.

See, much of Grails is an arrangement of preexisting technologies brought together with APIs sharing a common philosophy of simplicity and productivity. It’s not a reinvention of the wheel: it’s an alignment of existing cogs into a useful machine.

(That’s not to say Grails is a rehash of other’s work: my dabbling in Grails source shows that making Hibernate and Spring into its grokkable-in-ten-minute APIs is a Herculean task.)

Please forgive any misinterpretation I may put forth in the following: Graeme stated that he’s seen the core value of Grails being in the persistence API/GORM, simplicity of configuration/wiring, and the plugin environment. He followed with the thought that these are all way too valuable to isolate them in the Web world of the servlet container.

Going forward, he outlined that Grails itself shouldn’t be thought of as a Web framework but as an arrangement of plugins that currently provides Web capabilities. There’s no reason these plugins can’t be swapped, appended, and/or culled into rearrangements targeting other runtimes such as batch processing, big-data, or highly-concurrent Node-style service layers.

I completely agree, and I think it’s a great idea.

So Burt speaks up…

At this point Burt Beckwith brought up an idea from one of his coworkers: Grails should be renamed.

I think it’s a great idea. As much as I’d rather play with the bytes and build things, the half of me that’s become more business focused has come to accept some harsh realities. In this case, it’s that market perception of a product will often guide its success much more than its actual value.

(That’s unfair, I don’t like it, and I wish the world were different.)

Graeme expressed a frustration that Grails is continually compared to other Web frameworks when, in reality, it’s an architecture capable of being much more.

That brings me to my conclusion: I think Graeme’s inadvertently discovered Grails’ brand: it’s perceived as a lightweight way of knocking out quick and dirty Web applications in a WAR.

Again, I don’t think this is right, fair, good, or that it does justice to either the code its been written or the vision that’s been put forth.

Creating a new name would be doubly advantageous. The rearrangable “platform” can have its own identity, signaling a dedication to its purpose. Secondly, the “servlet profile” can still be called “Grails” – aligning its technical purpose with its market perception.

So, yeah, good session. Please forgive any misstatements or omissions: I did say there was beer involved.