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.

Whoa.

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.

Ollie Jones has written up a great post on his blog entitled "Mach-II and ColdSpring for N00bs." It's excellent information, very thorough, and very well presented. He even includes a zip file of his basic setup that you can download.

Thanks Ollie! I'm sure this will be extremely useful to a ton of people starting to learn Mach-II and ColdSpring.

As we said on the last ColdFusion Weekly, the 2007 Frameworks Conference was absolutely fantastic. Here are my presentations and code--enjoy, and let me know if you have any questions! If you're interested in MachBlog you can download it from the MachBlog web site.

Webapper just released an interesting summary of load testing the CFPetMarket in its various incarnations. (Go to cfpetmarket.com to download the different versions of the application.)

I don't think the results are all that surprising, so I won't belabor them here. What I do want to offer is a bit of my perspective on the issue of frameworks, CFCs, and performance in general.

First and foremost, remember that performance is one aspect of software development. Clearly our applications must have acceptable performance in order to be successful. What I'm afraid of is that people will look at these numbers and gravitate towards a "Fusebox is fast, Mach-II is slow" line of thinking. Mach-II is slower than Fusebox, but as the Webapper folks and Simon Horwith both point out, this is to be expected based on the CFC-heavy nature of Mach-II applications.

Note that I said Mach-II is slower than Fusebox, but that doesn't at all mean that Mach-II is slow. Performance is one aspect of software development, and if that was the only aspect of it, then we could all spend our time writing ultra-fast code that is unmanageable and perhaps even unreadable. We also have to maintain what we write, and this is where frameworks in general, and specifically Mach-II in my opinion, excel. That's not to say Fusebox isn't a great framework choice as well, I just think that for CFC-based development Mach-II is preferable. (I know, I'll probably get some contrary opinions on that, which is fine.)

The point I'm trying to make is that raw performance numbers aren't everything, and speed is relative. Think "fast enough," not just "fast," and always be mindful of the maintainability of your applications which in my opinion is FAR more important than raw speed. Maintenance is where all the money is spent, so as long as the application performs well (which Mach-II applications most certainly do) but is also easily maintainable, it will be a success over the long haul, not just in isolated load testing scenarios.

The Fusebox and Frameworks 2005 Conference was this past week and as always, Michael and all the folks at TeraTech put on a first class event. It was fantastic to get the opportunity to talk to attendees about Mach-II and the exciting stuff we put in the 1.1.0 release (available very soon!) as well as what we have planned for future releases. There's a ton of very exciting stuff going on with CF frameworks in general so here's my roundup of what I found most interesting at the conference.

 

Mach-II:I gave my Head First Mach-II presentation twice (PowerPoint and sample app code available soon), led a Mach-II Birds of a Feather session, and Ben Edwards gave a Mach-II Under the Hood presentation, so Mach-II had a strong presence at the conference. I got comments from lots of attendees after my presentation that they were now no longer "afraid" of Mach-II, and current Mach-II users were very excited to see all the activity going on in the Mach-II community these days, so this was fantastic. With the 1.1.0 release we're going to have a lot more and a lot better documentation, and when I have time I'm going to do my presentation as a Captivate demo, so you should have some excellent resources in the very near future.

I think the thing to remember about Mach-II is that if you put in the time to learn OO (which is a MUST these days!) then Mach-II is actually VERY simple to learn. It's based on some very basic principles and once you get the hang of those it's off to the races. Mach-II is a mature, stable framework that's proven itself in numerous very large applications so it's definitely worth a look if you haven't checked it out yet.

Spring, ColdSpring, IoC, and AOP: I know, lots of acronyms in there, and I'll be saying a lot more about all of this in the future. Max Porges gave a GREAT presentation about using Spring with a Java model in ColdFusion applications. At its most basic level, Spring is a framework built on the idea of Inversion of Control (IoC), aka Dependency Injection, and also supports Aspect Oriented Programming (AOP). This is extremely powerful stuff based on the simple idea that your model should be completely unaware of your framework, and also that each object in your model should be as unaware of other objects in your model as possible.

If that sounds great but you'd prefer to build your model in CFCs instead of Java, you'll definitely want to check out Dave Ross's ColdSpring as well as Chris Scott's ColdSpring AOP. Dave and Chris are working together (and quite obsessively, I might add!) on both of these initiatives and coming up with some amazing results. I talked with them pretty extensively at the conference and really like where they're going with things. I'm going to be using ColdSpring on an upcoming project so I'll have a lot more to say about it in the not-too-distant future.

Fusebox: Fusebox is of course alive and kicking, and even though I was never a fan in 3.0 days, Fusebox 4.1 has a lot of nice features and is definitely worth checking out, particularly if you don't have much OO experience. The very cool thing about Fusebox is that you can build extremely well-organized, easy to maintain applications using procedural principles, then move into using an OO model with Fusebox, and at that point if you're looking for something more purely OO, you'll more or less have the skills you need to move into something like Mach-II. I also love all the fantastic tools available for Fusebox, and the fact that you can very easily farm out discrete portions of the application development to people who don't need to have any idea about the application as a whole. This is powerful stuff for team development, particularly for a geographically disbursed team.

Model-Glue: Joe Rinehart gave some great presentations on his Model-Glue framework, which has been described by many people (to me anyway) as a kind of hybrid between Fusebox and Mach-II. It uses many of the same principles as Mach-II but could be a bit more approachable if you're coming from a non-OO background. Model-Glue is getting a ton of attention these days, Joe's an extremely sharp guy who works very hard on it, and given the adoption as of late you'll have plenty of help getting into it. The 1.0 version was just released and is definitely worth a look.

Tartan: Paul Kenney's Tartan Framework is a ColdFusion framework designed around Service Oriented Architecture (SOA). The basic idea between SOA is that components of your applications should be extremely loosely coupled (always a good thing!), and to achieve this SOA is based on a service layer to which your application components make requests and from which your components receive responses. If you're thinking "web services" at this point you're on the right track. Tartan can be an extremely powerful addition to other frameworks such as Mach-II, particularly if you want to do something like create a Mach-II application and put a Flash or Flex front-end on it, which Mach-II wouldn't really be able to accommodate on its own.

The onTap Framework: S. Isaac Dealey's onTap Framework has been around for quite some time, and I had the opportunity to hear him present on it several times back when he was a member of the DFW CFUG. My own take on onTap is that it's based on the idea of automatic execution of filepaths, and it's not entirely dissimilar to the way Fusebox approaches things, albeit with less explicit configuration of things. (Isaac, please correct me if I'm totally off-base here!) The most powerful aspect of onTap is the huge API/function libraries Isaac has included in the framework; think Ruby on Rails for ColdFusion. Automatic database tie-ins, automatic form generation and validation, really slick HTML libraries that make building slick DHTML interfaces dead simple ... there's lots of stuff in here to make your life easier.

Other Frameworks, Methodologies, and "Non-Frameworks": As always conferences get extremely busy, so in some cases I found myself caught up in conversations and missing some presentations I initially wanted to attend. Neil Ross presented on his framework TheHUB but unfortunately I missed that session. John Paul Ashenfelter presented on Ruby on Rails, which was admittedly a bit bizarre given that this was a CF conference. I missed the presentation but from what I heard it was full of the superlatives that seem to be part and parcel of the Rails community. Not that I think Rails is a bad idea necessarily, but it certainly isn't the silver bullet they make it out to be, and regardless of anything else it's still Ruby at a language level which I think would be a hard sell in a corporate environment. (Just my opinion.)

Since it's been discussed to death in other blogs I'll leave my comments about the "non-framework" contingency of one that was at the conference to a minimum. Let's just say I had an Emperor's New Clothes moment or two during discussions and presentations of this ilk.

All in all it was a GREAT conference, and definitely shows that the ColdFusion community is at a tipping point. The days of CFers not knowing what OO is and being aware that they need to gain these skills are coming to a close, and with the wealth of world-class tools that are in the works, we're soon going to have a set of enviable tools at our disposal to build powerful, flexible, maintainable ColdFusion applications in ways we never thought possible even as recently as three years ago. It's an exciting time to be a ColdFusion developer!

Comments

The recent discussions around ColdFusion frameworks, specifically the Mach-II vs. Model-Glue debate is, in my opinion, getting a bit overly frenetic and verging on just plain silly. Recent posts on CF blogs such as Mach-II is Dead! and Is Mach-II an Ex-Framework? (which is admittedly just a link over to the "Mach-II is Dead!" entry but certainly adds fuel to the fire) have the tone of a bad disaster movie from the 70s. The plane's not crashing into the ocean, the skyscraper isn't burning down, there's no earthquake that's going to make half of the United States fall into the ocean. Take a deep breath, relax, and let's discuss all of this rationally for a moment.

Don't get me wrong, I'm a big framework proponent, I like Mach-II, I like Model-Glue, and I think there are great benefits to developing with frameworks. Joe Rinehart, Hal Helms, Ben Edwards, and everyone else who contributes in one way or another to this aspect of the CF community all deserve a round of applause in my book. Where I think the recent discussions have jumped the shark a bit is because they're beginning to ignore why we use frameworks: to build applications. When you spend more time thinking about frameworks than you do using them to build applications, something's a bit out of whack in my mind.

Mach-II is a great framework. Yes, it's stagnated a bit compared to Model-Glue (which is younger, therefore you'd expect more activity surrounding it and more frequent updates), but it's not as if it's going anywhere. Mach-II isn't suddenly going to evaporate and render all Mach-II apps null and void. If you like Mach-II then by all means use it. The framework code doesn't die or go bad like that stuff in the back of your fridge that you forgot about. It will continue to work for a long time to come. There is of course the issue with finding someone with Mach-II skills if they have to take over an application written with Mach-II, but it's not as if a competent CF programmer with OO skills won't be able to figure out Mach-II if they have to.

Model-Glue is also a great framework, it has some nice features Mach-II doesn't have, it eliminates some of the complexity of Mach-II, and I like it a lot from what I've done with it so far. Phrases associated with it like "wildly popular" tend to be a bit skewed in my mind, however. Reading blogs tends to provide a skewed perspective on the world anyway, and nowhere in the CF world has this been more true recently than the framework frenzy. Let's try to keep this all in perspective.

The other thing these sorts of discussions do is make people scared to jump in and work with frameworks because they're afraid they will make a "wrong" choice. I can just hear people saying, "Phew! Thank god I didn't waste my time with Mach-II! It's DEAD!" Utter nonsense. Whether or not you choose to write a particular application using a given framework is something you have to ponder a bit of course, but this whole discussion is just getting blown WAY out of proportion in my opinion.

I understand the point of view that Mach-II's future is a bit in question, but it's a solid framework that has a lot of great benefits, and until a new version of CF breaks it (which it may or may not), it's going to work fine. If you think Mach-II has stagnated too much then don't use it, or take the ball and run with it (meaning pick up where you see Mach-II as having "left off" and roll your own version).

I also applaud Joe Rinehart for his attention to the small-but-growing (again, keeping this all in perspective) Model-Glue community, and I greatly appreciate the framework itself and his responsiveness to its users. ColdFusion needs as many people like Joe in the community as we can get, and Model-Glue is admittedly becoming my framework of choice these days. My point is that I'm not trying to bolster Mach-II or take away from Model-Glue; I've just been laughing out loud when I've read some of the blogging about all of this lately.

I've written a lot of Mach-II applications since it came out. Am I going to worry about them breaking because Mach-II is "dead" or feel that I need to rebuild them all in something else? Of course not. They run great, they're easy to maintain, and they'll continue to run great until some fundamental change in CF breaks Mach-II (which it can potentially do to ANY framework remember), which may or may not even happen.

Will I write more Mach-II applications in the future? Maybe, maybe not. The jury's out on that one. I'm still getting up to speed with Model-Glue and I like it a lot, and given the tremendous support Joe's giving to it it's definitely an attractive framework, particularly for people with Mach-II and OO experience. However, if in some particular case Mach-II seems to be a better fit for one reason or another, I'm not going to avoid it just because it's falling out of favor with some folks. If I was worried about using the most popular framework in CF, I'd use Fusebox exclusively (and as an aside I've been spending a significant amount of my spare time learning FB 4.1 lately).

So the bottom line in my mind is that everyone needs to take a deep breath, step away from the computer for a bit, and come back to all of this with a bit more rational head. Your server's not going to start on fire if you choose the "wrong" framework, and you aren't permanently sealing your fate by choosing one over another. Remember: this is all about building great applications, it's not about becoming a framework junkie (fun as that is) just for the sake of becoming a framework junkie. Learn and use as many frameworks as make sense for you to learn and use, observe the progression among the various frameworks, and by all means take all of the blogging about this (mine included) with a grain of salt.

It's interesting and entertaining to watch all of this unfold, but at the same time I think the mob mentality going on may be causing people to lose sight of the end goal, which is building better, more solid, more easily maintainable applications, and frameworks go a long way toward reaching these goals. I'm just glad that as CFers we finally have multiple great frameworks from which to choose.

Comments