Skip to main content

I'm Having a Crisis of Faith After a Weekend with Grails

I have a confession to make: I cheated on CFML this weekend. And I enjoyed every minute of it. Heresy, I realize, but if you stick with me through this brain dump I hope you'll see that despite the sharp criticism contained herein, I'm extremely optimistic about the future of CFML. We just have a helluva lot of work to do.

To set the stage for things, I'm embarking on a side project with a friend of mine and as usual it's a big job with a tight deadline. None of this is anything new and previously I wouldn't have thought twice about which technology to use. CFML: Now More Than Ever. (Sorry, I just love that bumper sticker.)

I've been taking several runs at Grails over the past year or so, and with a semi-free weekend I decided to re-read a few books and some issues of GroovyMag. Basic requirements for the aforementioned project in front of me on Protoshare, I figured I'd give myself an hour to get a couple of the domain classes up and running in Grails. I downloaded fresh versions of Groovy and Grails and set off to work.

I didn't need the whole hour. I didn't even need half an hour. About 10 minutes after getting everything installed, and this included reading a couple of refresher instructions (and truth be told I ate a little sushi while doing all of this), I had my basic domain classes that involved a one-to-many relationship done, persisting to a database, tested, and the basic Grails master/detail views and CRUD functionality up and running. And before you think an IDE of some sort was lightening the workload, I did all of this in a terminal using vi.


Granted, I've done this sort of exercise before so Grails wasn't totally new to me. For someone new to Grails you might have needed the whole hour. ;-) Previously though, I'd screw around with inconsequential "Person" or "Book" or "ToDo" classes and think, "Impressive, but if I were doing this for a real application there'd be much more to it." But this time around I was starting at square one on a real project, so in my mind I was looking at Grails from the standpoint of building a real application with it.

I proceeded to build out more of the application, fully expecting to lift up a stone and find some nastiness I couldn't live with, but the hidden gotchas never came. Grails simply delivers.

A Concrete Example

Before moving on to my counterpoint that sets up the rest of this post, let's take a quick detour to see how Grails does what it does. To prove I'm not blowing smoke, this--literally and with no omissions--is what you have to type in a terminal to have this working Grails application up and running. (Be nice if you add stuff there. Your mother might read it.)

First, you create the application and have Grails generate a couple of objects:

grails create-app UserTest
cd UserTest
grails create-domain-class User
grails create-controller User

That creates the application and two files, User.groovy and UserController.groovy.

You then add this to User.groovy:

String email
String firstName
String lastName

You then add this line to UserController.groovy:

def scaffold = User

And finally, you run the application:

grails run-app

That's it. You've just built out the basic CRUD operations for a User class in about two minutes. And if you don't like the terminal, NetBeans makes this even easier.

Want to deploy the app to another server? Type:

grails war

Then drop the generated WAR file on any Java servlet container. Granted this is using HSQLDB at this point, but having it point elsewhere is a matter of tweaking a DataSource file and setting your production database to whatever you want. Grails is smart enough to handle different environments (e.g. development vs. production) and use the production database settings when you generate a WAR. (Yeah, they pretty much thought of everything.)

Stark Contrast

Back to my experiment. With some basic functionality for my app up and running so quickly in Grails I decided to open up Eclipse and go through my usual process of developing this same functionality in CFML. I'll be completely honest and say that this is not a fair fight, which kind of gives away one of the punchlines of this post, so read on ...

I haven't ever been a real fan of any of the code generators available for CFML, nor have I ever delved much into the CFML ORM tools. This is not a slight against the authors of those tools in any way; I've just always preferred to do things by hand. I do use Peter Farrell's Rooibos Bean Generator regularly since writing beans is pretty much the definition of drudgery, but my Mach-II listeners, my service layer, my DAOs, etc. have all been written by hand.

Why? Because I'm a control freak. Every time I'd try a code generator or ORM I'd be thinking, "That's not exactly the way I'd write it," or I'd be wondering what the heck the ORM was doing under the hood, or I'd be concerned about performance with an ORM, or any number of other excuses, so I never made the leap. I didn't want to give up the control. And I type fast enough and have done enough of the basic grunt work that it's not as if I was adding a ton of time to my projects. A few days on most typically sized projects for me and the basic plumbing would be done. Not so bad.

To even begin to approximate the Grails test I started from scratch with the CFML application as well, other than my existing Eclipse/CFEclipse and Tomcat installation. (For those who aren't aware, Grails comes with literally everything you need to run it including Jetty.)

I downloaded an Open BlueDragon WAR, Mach-II, the Mach-II Dashboard, the Mach-II skeleton, and ColdSpring ... all the familiar faces I'm used to seeing in most of my projects these days. I then set out to write all the same code that existed in the application that Grails scaffolded for me, which involved:

  • Creating a database (I used H2 to keep things simple)
  • Creating two domain classes with a one-to-many relationship between them
  • Creating a controller for each domain class
  • Creating a list view and the related queries for each domain class
  • Creating an add/edit form and the related queries for each domain class
  • Creating unit and integration tests for each domain class

In short, all the stuff you'd need to get a nice head start on the backend of any web application, and nothing more than what Grails gave me in 10 minutes.

I downloaded files. I unzipped files. I moved files around. I edited config files. I wrote code. I edited more config files. I wrote more code. I wrote a lot of freaking code.

A couple of hours later, I had something that approximated my stopping point on the Grails experiment. But it wasn't as nice, and I had to be honest with myself: it was a horrendous amount of work by comparison.

I didn't even get to the testing part, for which I would have had to download MXUnit and create test CFCs and functions. I gave up and went to bed.

It's All Relative

Before people think the situation is too dire, let's keep things in perspective. Creating a working prototype of a couple of major pieces of a web application in a couple of hours really isn't that bad in the greater scheme of things. As I said earlier, it's not as if we're talking about adding weeks to a project schedule by doing things this way (though I suppose on huge projects time spent here would add up). And of course if all I wanted was pure development speed I could have done old-school CF 5 style development and been done with it, but that's not a good way to lay the foundation for a extensible, maintainable application.

On the other hand, everything's relative. After the instant gratification from Grails I had to face the fact--and I hope everyone understands how difficult this was for me--that working with CFML was like running in bare feet on the sand, and working with Grails was like having that jet pack we've all been promised for so long.

I didn't plan on winding up where I did when I fired up Grails the other night. It's not as if I'm fed up with CFML and was looking for something different, and I had no intentions of taking a bit of a hard right turn on this particular project and going with a technology that truth be told I'm still not all that familiar with. But here I am. And I'm not sure I can look back.

No, This is Not One of "Those" Blog Posts

I'm not going to make a big speech about how I'm "leaving CFML" to raise a ruckus and get some attention. I care a great deal about the future of CFML or I wouldn't spend so much time on it. But the longer I've been in this business, and the longer I've been using CFML, and given all the tools and languages I've seen come and go over the years, I've become a lot more pragmatic than I used to be.

I've gone down a couple of dead-end paths over the years (any REBOL fans in the house?), and although each of us tend to have what amounts to a love affair with a particular language--the one we keep going back to time and time again, and the one that will always have a special place in our hearts for more emotional that practical reasons--we owe it to ourselves and the technology we love to be open to other possibilities, and to be brutally honest when something comes along that just plain works better. Admitting that isn't admitting failure: it's admitting that you care.

If we don't ever look outside our own little world, preferring instead to contemplate our navels, live blissfully in Lake Woebegone, and engage in full-blown siege mentality when we're threatened, then I'm sorry, that's not being dedicated to the technology we love. That's coding while Rome burns.

I realize this sounds pretty dismissive of CFML. It's not, but that's another punchline coming a bit later. CFML is the first programming language I learned after HTML, and 12 years later I'm still using it and still extremely excited about where it's going, particularly with the shiny new open source movement in CFML.

All this being said, I simply can't shake the experience I had with Grails the other night. The contrast between a sophisticated, well-thought-out, extremely well-executed, comprehensive framework like Grails (not to mention the elegance of the Groovy language) and the comparable tools we have available for CFML is too striking to dismiss or ignore. And again, that's not to denigrate the fantastic work anyone does on any of these tools. Remember, I'm involved with some of them myself and I don't plan on stopping those efforts. They're great at what they do, but what they do is no longer enough.

As I mentioned earlier I've taken a few stabs at Grails so I'm not quite sure what was different last night. Probably a whole lot of thoughts and directions and changes in my attitudes about things came together in a particular way and at a particular point in time and space, but whatever the reason, Grails opened my eyes wide last night, and I simply can't dismiss that. To quote one of my favorite movies, "How you gonna keep 'em down on the farm once they've seen Karl Hungus?"

What Changed?

If I'm totally honest with myself, probably the biggest change in my attitude towards development these days is I just want things to work. After writing CRUD code for so many years, not being willing to give up any control, and convincing myself I was doing my application a favor by writing every single line by hand, I'm tired.

CRUD crap (is that redundant?) is a commodity. Basic object generation is nothing more than a means to an end. Your users don't care a lick about your hand-crafted, finely tuned SQL, or your oh-so-clever service layer, and if you do, I'm reminded of the old adage about peeing your pants: it may give you a warm feeling, but no one else cares. Users want something with a great front end because to them that IS the application. As long as it's easy to use, it works, and it meets the applicable performance and scalability requirements, the application is successful.

So given the finite amount of time we all have, why would we consciously choose not to use a tool that does the commodity stuff for us so we can focus on the front end and business logic? I know SQL pretty well but I can't say I enjoy writing SQL. It's just something I felt I had to do. Same with so much other boilerplate crap. But if I had my druthers, I'd focus more on business logic and UI functionality and have all the persistence nonsense and a lot of the other drudge work handled for me. Not to mention the fact that when I'm using best-of-breed tools to do this, I can rely on the fact that the underlying code has been battle-tested by thousands of users. I can't say the same for my own persistence code until I put the app into production.

Grails isn't only about GORM of course. If I just wanted an ORM I'd use Transfer, and ORM capabilities are coming in ColdFusion, Open BlueDragon, and Railo. But Grails is about much more than ORM. ORM alone only gets you a fraction of the way there.

The real secret to the Grails sauce is how overwhelmingly compelling the entire package is, from the Groovy language itself, to GORM, to the fantastic flow and incredible speed of the entire development and deployment experience, to the powerful front-end tag library, to the integrated testing, to the sophisticated and dead-simple AJAX functionality ... I could go on. The point is Grails is a complete pleasure to use from top to bottom, and I'm finding it increasingly difficult to talk myself out of taking it seriously.

Apples and ... Different Kinds of Apples

Thus far you may have been thinking, "Is this guy a moron? He's comparing a language (CFML) to a framework (Grails)." To a point, that's true. But when I'm comparing Grails to CFML I'm just using CFML as a short-hand way of referring to the tools available in the CFML world. So I'm really comparing Grails as a package to the disparate bits and pieces that create some semblance of Grails-like functionality in CFML.

Take Mach-II for example, which in my incredibly biased opinion is the finest MVC framework for CFML. ;-) Peter Farrell, Kurt Wiersma, Brian FitzGerald, and I spend a ton of time on Mach-II, not to mention all the great help from our community, and it's a damn nice framework. It continues to get better with each release, and with caching, logging, the dashboard, the new front-end tag libraries, and everything else we've put into Mach-II and have planned for future releases, it's a really compelling package.

One of many things that struck me as I've been working with Grails is how the basic constructs of Mach-II map one-to-one with Grails. Grails has "controllers," Mach-II has "listeners." Grails has a flash scope to persist data across redirects, Mach-II has the same. The Grails docs talk about how to keep your controllers dumb and use a service layer for your business logic, just as we advise in Mach-II. Even the Grails code I've been writing, particularly the controllers and services, looks eerily similar to the Mach-II code I write. This is probably why I've found myself surprisingly comfortable in Grails so quickly.

But Mach-II is only one piece of the puzzle. To manage dependencies, we need to grab ColdSpring and wire everything together in an XML config file. If we do want ORM, we have to grab Transfer or Reactor and again, more configuration. Then we grab MXUnit for testing, and it's yet another piece of things that knows nothing about any of the other pieces of our puzzle until we explicitly tell it. If we want to do functional testing we grab Selenium. And round and round we go.

Ultimately it's not that we lack the tools in the CFML world that give us the ability to do what Grails does. Heck, Grails is based on Spring, Hibernate, JUnit, and other best-of-breed tools in the Java world, so it's not as if the Grails authors created this entirely from scratch.

What we're missing in the CFML world is flow, and without good flow you simply don't have good productivity.

Integration, Integration, Integration

I won't belabor this point too much since I've made it in other ways a couple of times now, but the magic of Grails is the cohesiveness with which all the various bits and pieces of the web development process have been integrated. MVC, DI, ORM, unit and integration testing, functional testing, i18n, AJAX, deployment, documentation, even a run-time environment ... literally everything is contained within Grails, and it all works seamlessly. It's magic.

This elegant integration of what in the CFML world are still very disparate tools is what makes Grails such a joy to work with. I've never experienced a better development workflow than what I can achieve with Grails, and this leaves me free to focus on the things that matter most to the success of my application. And for simple applications I can crank stuff out more quickly than ever before.

That's what I kept coming back to as I fought with myself over whether or not to use Grails for a real-world application. In the end, it's all about the success of the application and how I can do the best job possible in the shortest amount of time. Much as I love CFML, in this case Grails won out. Even with my years of experience with CFML and relative lack thereof with Grails, I had to have a heart-to-heart with my friend (after the one I had with myself) and tell him that I truly believed I could get things done more quickly and with a better end result than I could with CFML, at least for this particular project. After showing him a demo or two of what Grails can do and writing some live code to show I had nothing up my sleeve he, another long-time CFML developer, had to agree.

Yes, it's a poor craftsman who blames his tools. But you sure can cut the grass faster with a lawnmower than you can with a pair of scissors.

Why Grails

I'm well aware that this is the honeymoon period between me and Grails. I'm sure we'll fight. But I'm equally sure we'll make up. The real test will be building an actual application with it, and I'll have a lot more to say as I do.

At least at this point in my experience with Grails, it strikes the perfect balance between taking the drudge work out of web development while still letting you have full control over the stuff that matters. This is the promise of CFML, but compared to Grails we're not there yet.

As for going with something like Spring, I like Java, I really do, but Java Sucks Ass. It's documented. (Be sure and read the follow up post to that one.) So Groovy gives me a faster, dynamic version of Java, and Grails gives me a fantastic toolkit to get great stuff done quickly. This way I keep what I love about Java in the mix without having to make a massive sacrifice in productivity.

Can Ruby on Rails do all this stuff for you? Sure. Grails used to be called Groovy on Rails (no way!) until DHH requested a name change (at least that's what wikipedia says), so clearly the Grails folks thought Rails had a ton of good ideas in it. I've also dabbled in Ruby and Rails a bit over the years, but as a language Ruby just doesn't do it for me. I'm sure many people out there love Ruby, and that's fine. For me Grails is a much better fit, not to mention the 100% seamless integration with Java when I need it.

Why Doesn't CFML Have a Killer Framework Like Grails?

Honestly I'm not even sure the "why" even matters. I have some ideas about why CFML isn't farther along than it is given its lengthy history, but I'll save those for another post. Fact of the matter is we have the makings of what could be a great development experience, but we don't have the whole enchilada. Not by a long shot. We deserve better. We can do better.

What would make up a Grails-like framework in CFML? Here's the basic pieces:

  • CFML runtime
  • MVC framework
  • ORM framework
  • Logging
  • Caching
  • Unit and integration testing framework
  • Front-end/functional testing framework
  • JavaScript/AJAX framework
  • Templating engine
  • Command line tools for code generation, scaffolding, deployment, etc.

If you're saying "we've got all that," on most points you're right, and with the view tag library in Mach-II 1.8 we're even getting there on the templating engine front. But we're still lacking all of this in a single easy-to-use package that increases our productivity in CFML by leaps and bounds. One could argue there's still less typing in CFML than in other languages, which is a dubious argument at this point given things like Ruby and Groovy, but we're still lacking the proper tools to truly make developing an application, not just writing code, far more productive in CFML.

So let's go down the list and figure out how we'd make this happen.

Building the Perfect Framework

You can't run CFML without a CFML runtime, so the CFML engines are certainly part of the puzzle. My only cautionary statement here is we can't rely on them to give us the CFML version of Grails. In my opinion that isn't their job. To create a development experience similar to Grails, having the ability to easily plug in and distribute (that's key) a CFML runtime is crucial. The distribution part is where Adobe ColdFusion is a non-starter, but of course the magical CFML framework that exists in my head would allow you to choose OpenBD or Railo as your runtime, and those could be bundled, or you could plug Adobe CF in after the fact if you so choose. To me having everything in a single downloadable package eliminates one more headache and much more closely approximates what you get with Grails.

ORM is another piece of the puzzle. We have Transfer and Reactor now, and we have ORM support being baked directly into the CFML engines as we speak. Again no offense to the Transfer and Reactor folks, but I think once Hibernate, or JDO, or some other implementation of the JPA is baked into all the CFML engines, or even just available as a seamless add-on to CFML, we'll have a much bigger step forward on this point. I've used Transfer a bit and it works great, but there's no substitute for the thousands of man hours of development and testing, not to mention the wide usage, of the ORM tools in Java. Java's just a much bigger pond and I think we can benefit greatly from leveraging it whenever we can.

As for MVC, here's where I'm going to get myself into trouble, but I don't think the CFML world needs a dozen MVC frameworks like we have now. The CFML community is way too small to have so many people spending so many man hours reinventing the same wheel over and over again. Now of course I'll admit my bias and say I think as a whole Mach-II gets us closest to the final result we need, but ultimately what I'd like to see is all the framework authors working together towards a common goal even if the people behind the various frameworks still choose to do things their own way. Maybe the magical framework in my head exposes an API that all the MVC frameworks implement so you're free to pick your poison on that front as well. (As you can tell, I'm still thinking through how all this would work.)

As for the rest of the pieces the choices are obvious. For JavaScript and AJAX, jQuery would be rolled in but you could use another framework if you choose. Pluggability is key here as well. Mach-II is well on its way to having a full templating engine built in, but there may be other projects out there in CFML land that I'm not aware of. For unit testing we have MXUnit. For front-end testing we'd have to leverage something like Canoo, or maybe Selenium is equally configurable and scriptable (haven't looked at it in a while).

Command line tools are where things get interesting since you can't run CFML commands from a terminal. (Anyone working on that?) So, two thoughts come to mind. Either this is all web-based, which is OK, or Java and ANT are used to do the command line pieces. Maybe we have both options. (I can ask for the world when this all exists only in my head.) I do think the command line bit is key, not only because I like working that way, but because it's a faster, easier way to do things than clicking around on web pages.

So put all this and some awesome scaffolding together and you're done! Yes, I realize what I'm proposing is a tremendous amount of work. Grails was three years in the making before it hit 1.0. So it's not that it can't be done, we as a community of framework authors and CFML advocates just need to commit to making it happen and start chipping away at the mountain of work involved to get there.

The Punchlines

I said I had some punchlines, and though you've probably assembled then in your head by now after reading everything to this point, I'll just enumerate them so they're more, uh, punchy.

  1. Grails kicks ass, and we deserve something this awesome in the CFML world. We should have had it by now. We don't need more frameworks, we need to demand more from our frameworks.
  2. We need to collaborate more as a community and work towards common goals instead of everyone being off in their separate caves cranking out code that does the same thing as what the guy next door is writing. Specifically I'm targeting those involved with framework projects, myself included. I'm not even necessarily proposing one framework to rule them all, but it does seem a bit silly that as a relatively small community we spend such a huge amount of time and effort to wind up with such subtle differences in how the various frameworks do their respective jobs.
  3. We need a vision. I've tried to present one here, although as you can tell at this stage it's still a bit cloudy. But we need to open up the dialogue and remove our egos and biases from the picture and answer the question: What would the perfect set of tools for CFML development be?
  4. We need an action plan. I haven't thought that far ahead quite yet, but the first thing that comes to mind is a framework authors mailing list. Maybe there already is one. And it's key that this discussion be completely open and anyone who has interest, framework author or not, can participate. From these discussions we can quite easily come up with a high-level, concrete set of tasks and goals and get to work. I'm not saying it's going to be easy, but on the other hand I feel like we have all the basic building blocks available, so how hard can it be? ;-)

Who's With Me?

If the ideas in this post scare you, good. They're meant to. But they're also meant to motivate you. If you care about CFML as much as I do, then I hope you have the courage to admit that we're falling behind and that we need to do something about it. This doesn't mean blogging, and twittering, and conferencing, and defending CFML against all enemies domestic and foreign, and all the rest of the community-oriented stuff we all do. This means coming together as a group, knuckling down, and doing some seriously hard but even more seriously rewarding work from which we all will benefit.

We can do this. We need to do this.


henrylearn2rock said…
Yes, agree wholeheartedly. :)
virtix said…
good post, matt.i agree that cfml would benefit from more collaborative innovation and less individualism and protectionism. what adobe is doing with cf9 is awesome, what railo is doing with performance and other features is equally as impressive, and what open bluedragon is doing with google appengine is *very* cool. but who can deny that all this is causing fragmentation? i've experimented both grails and rails apps and *really* like the ease of scaffolding and the minimal amount of code. with cf9 + hibernate + front-end technologies, i can see how it would pretty easy to do some ColdRails thing. throw in some automatic test generation, of course, and you're good to go ;-)in my most recent experiments into google appengine (python), i came away very impressed by the brevity of the code it took to generate and deploy an app. also, there was no initial domain setup or hosting costs. using bigtable and python classes is mind blowingly cool and simple, but a leap for the relational mind. another thing that caught my attention was the templating, which is an earlier version of Django's templating. very cool inheritance in templates and saved me a ton of redundant html, made my presentation tier clean and DRY. something like this, for me, is now a framework must have. the vision is important, and i would tie it to a good purpose, as well. what should the goal be? to help the community? to help cfml? to be honest, i don't know if that's enough to sustain *any* effort. take a look at Matz. as i understand the story, he didn't build Ruby for "the community" as his main goal - he was his own customer. i think if you build something that you need and will use, it will be a good product that others will also use. another case in point, the herman miller aeron chair (just got one). check out bill stumpf's awesome videos on how he designed it: for his own butt.bill
Peter J. Farrell said…
I'm already with ya buddy! Viva la resistance!
Matthew Woodward said…
@Bill--I definitely agree, and believe me the motivation I have at this point is because *I* want this stuff. I was frankly a bit pissed off while using Grails that we don't already have this stuff in CFML, so it served to get me pretty motivated.But I also realize if we're going to get there in any reasonable timeframe, it'll take more than my own personal motivation to get it done. I feel like as a community we've burned a tremendous amount of time collectively that could have been used to move towards a killer solution.I'm sure one person could pull this off given enough time and motivation, but since we have all the pieces already, all I really think we need is a good strong vision and everyone helping the people involved with putting the pieces together to make it happen. That'll get me there, and all of us there, a lot faster than someone once again re-inventing the wheel.
jdowdle said…
Amazing post. Bookmarked to read in the AM so I can soak this beauty up 100%. Great job Matt.
bdensmore said…
I've been thinking along the same lines Matt. I recently did a project where I had to use PHP. Not knowing PHP that well I decided to see if there were any MVC Frameworks that I might like.I found the yii framework( I have not used Grails before but it sounds like yii and Grails have some very similar features. It comes with a command line tool where you type in something like "model User" and then uses scaffolding to build out your Model View and Controller files. I immediately thought to myself, why hasn't any of the CF Frameworks added something similar. Most projects start out with your basic CRUD methods anyway, if I could have something generate those methods for me and give me a starting point, I could start getting into the more advanced work that might be left right away instead of writing or modifying those CRUD methods.I too love CF, and it is the first language I ever used but I do see some of the other technologies offering some useful features that we lack in the CF community.I would love to see these ideas incorporated and it sounds like that could be the road Mach-II 2.0 or later could be going after reading this post. I hope to see it sometime sooner rather than later.Excellent post Matt.
Matthew Woodward said…
@bdensmore Thanks for the Yii link--hadn't heard of that one. I like the fact that it supports both DAO and active record; that's something I still struggle with since I like the convenience of active record but also like the fact with a DAO that my model objects don't have persistence mixed in. Grails keeps this pretty transparent, but being able to support either method is definitely something to consider.
Peter J. Farrell said…
Matt really gets at the point here what needs to be accomplished and that it takes work. The problem is finding people that will be dedicated to starting what they finish and not scared to contribute.I think one of the problems in the CFML community is that I feel that most developers feel a bit insecure about their "quality" of code. However, this really shouldn't be a problem because that's where the value of open source really shines. The more eye balls on the same code means it consistently gets improved and gets better over time. This is where I've really tried to be helpful when people contribute to Mach-II (if I can get somebody to this point) is to really treat it as peer review and attention to detail. I do this because I've been schooled in many areas by other people's code.You don't have to cream of the cream of the cream of the crop to contribute to open source. You just have to willing think about stuff and make revisions. Actually, I've learned more about writing quality and full featured code from contributing to Mach-II than I've ever learned from my day job (and I have a varied day job). I really attribute my personal success as a developer because I became involved in open source.The way for an open source project to be the most successful is to have a plan and to think about how to architect things. Most CFML open source project only have one developer and personally this is not an optimal situation because there is no "group think". For example, sometimes I'm tasked to architect something in Mach-II. After a lot of thinking, I start to feel like I've come up with a great solution (feeling rather smart about it) and then I talk to Kurt / Matt and I realize a ton of things that I didn't plan for. This "group think" leads to a better product or feature.So I encourage anybody reading this to get involved in open source and to be greedy -- get involved with Mach-II. I promise nobody on Team Mach-II will bite (well, maybe Matt ;-). Feel free to get in contact with us via's contact us page.
cf_chrispeters said…
I encourage you to give ColdFusion on Wheels a look and give us some feedback, though I completely understand that your allegiances are with Mach-ii. :)I also feel the sentiments about fragmenting an already-small developer community with yet another framework. This very issue caused me to take a big pause a couple years ago when I decided whether or not I was going to take the plunge and let this thing live on.Since then, we've been very fortunate to have a few people dive in and start submitting patches to improve things, and as new people dive in, they've been pointing things out that we can do better. So I see exactly what Peter is saying above in his comment.I don't know what point I'm trying to get across other than, "we're here" and our long-term vision is in line with the issues that this post
graemerocher said…
Why not write a CFML plugin for Grails so that you can continue using CFML as your view technology, but take advantage of Grails great server/db features like GORM. Best of both worlds :-)
Matthew Woodward said…
Wow, *the* Graeme Rocher? I'm flattered!A plugin for Grails isn't something I had considered so thanks for the suggestion. I'll look into that. I see you're doing two sessions at SpringOne on plugins so I'll definitely hit those sessions.
elegant_chaos said…
Great post Matt! I agree wholeheartedly with your sentiments. I see no reason why we cannot have a Grails equivalent in CFML, except for the fact that it would take a lot of resources, and most of the willing resources are already contributing to other open source initiatives.That is good. If it wasn't for committed individuals we wouldn't have resources like Coldspring, Transfer, MXUnit, and a number of excellent MVC frameworks. I don't imagine that anyone spearheading any of those projects would have been willing to take on a full-stack framework, as it's just so much work. In fact, I believe, based on what I've read, that most framework authors specifically try to limit the scope of what their framework does. I think that works out well for those individuals who don't want a full-stack framework, and are only looking for a DI solution or an ORM solution (for example).I think from your post that you are considering that combining multiple existing frameworks is a possible solution (as opposed to trying to create a new framework from scratch that does everything), and I think that might make the most sense. That would allow the current authors to continue to innovate their frameworks, and make those improvements available to those who prefer to use individual frameworks, but would also allow them to be used as part of the stack.The API idea is interesting, particularly as I imagine it will be next to impossible to pick one MVC framework to include in the stack, and expect the majority of CF users to go with it.This idea is something that I've been toying with in my mind for quite awhile now. I have my own favourite frameworks and tools that I often combine in projects, and to me the next step was to start defining and utilizing more metadata so I could allow each of those frameworks to work together as a group, generating my model and views for me. The main reason I haven't taken that idea forward is that I didn't want to create "yet another framework". If we could truly get people behind this idea, and marshal resources, rather than creating yet another competing framework, I think we'd end up with something amazing.Colour me interested, and count me in!
John Allen said…
Awesome post. I couldn't agree more. I to have been thinking "we have the coolest language, why don't we have a RAD framework"@elegant_chaos - metadata to have frontController/ORM/Testing/Scaffolding work togeather... interesting.Count me in.
Anonymous said…
Jon Karna said…
You've completely changed the way I think about coldfusion in just a weekend. Ever since I tested out ror, I've been wishing that coldfusion had something that worked like that. In combination with your post(s) about coldfusion on tomcat, I think I am going to give groovy on grails a test run.
Matthew Woodward said…
Cool--be curious to hear what you think.

Popular posts from this blog

Installing and Configuring NextPVR as a Replacement for Windows Media Center

If you follow me on Google+ you'll know I had a recent rant about Windows Media Center, which after running fine for about a year suddenly decided as of January 29 it was done downloading the program guide and by extension was therefore done recording any TV shows.

I'll spare you more ranting and simply say that none of the suggestions I got (which I appreciate!) worked, and rather than spending more time figuring out why, I decided to try something different.

NextPVR is an awesome free (as in beer, not as in freedom unfortunately ...) PVR application for Windows that with a little bit of tweaking handily replaced Windows Media Center. It can even download guide data, which is apparently something WMC no longer feels like doing.

Background I wound up going down this road in a rather circuitous way. My initial goal for the weekend project was to get Raspbmc running on one of my Raspberry Pis. The latest version of XBMC has PVR functionality so I was anxious to try that out as a …

Running a Django Application on Windows Server 2012 with IIS

This is a first for me since under normal circumstances we run all our Django applications on Linux with Nginx, but we're in the process of developing an application for another department and due to the requirements around this project, we'll be handing the code off to them to deploy. They don't have any experience with Linux or web servers other than IIS, so I recently took up the challenge of figuring out how to run Django applications on Windows Server 2012 with IIS.

Based on the dated or complete lack of information around this I'm assuming it's not something that's very common in the wild, so I thought I'd share what I came up with in case others need to do this.

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Assumptions and CaveatsThe operating system is Windows Server 2012 R2, 64-bit. If another variant of the operating system is being used, these instructions may not work properly.All of the soft…

Setting Up Django On a Raspberry Pi

This past weekend I finally got a chance to set up one of my two Raspberry Pis to use as a Django server so I thought I'd share the steps I went through both to save someone else attempting to do this some time as well as get any feedback in case there are different/better ways to do any of this.

I'm running this from my house (URL forthcoming once I get the real Django app finalized and put on the Raspberry Pi) using I don't cover that aspect of things in this post but I'm happy to write that up as well if people are interested.

General Comments and Assumptions

Using latest Raspbian “wheezy” distro as of 1/19/2013 (’lll be using Nginx ( as the web server/proxy and Gunicorn ( as the WSGI serverI used heavily as I was creating this, so many thanks to the author of that tutorial. If you’re looking for more details on …