An Architect's View

CFML, Clojure, Software Design, Frameworks and more...

An Architect's View

Which is the greatest ColdFusion framework?

April 12, 2008 ·

That's a question that crops up over and over again. I've blogged about it in the past. My answer - as I'm sure most folks would expect - is "it depends". The question came up on a mailing list again the other day and someone jumped in full of praise for ColdBox and then someone else said "Sean would say it depends" and went on to plug cf.Objective() as the "perfect place" to answer the question, wishing they could be there. Here's what I said in response:Thank you for the plug. Yes, cf.Objective() has lots of framework sessions that can help answer these sorts of questions:
  • ColdBox - intro session and advanced two-hour hands-on workshop
  • ColdSpring - two-hour hands on workshop
  • FarCry - overview of new 5.0 release
  • Fusebox - overview of new 5.5 release
  • Mach-II - two sessions (building enterprise apps; what's new in 1.6 & 2.0)
  • Model-Glue - intro to 2.0 release; overview of upcoming 3.0 release; using ColdFusion 8 AJAX features with MG2
  • Reactor - performance tips & tricks
  • Transfer - intro session and advanced caching session
Also an internationalization session for frameworks and a birds of a feather session. All the major framework authors will be present so you can get information right from the horse's mouth. So, at the risk of hijacking [this] thread, if you want to learn about frameworks, hurry up and register for cf.Objective()! :)

Tags: cfobjective · coldbox · coldfusion · coldspring · farcry · fusebox · machii · modelglue · orm

20 responses

  • 1 Jim Priest // Apr 12, 2008 at 1:42 PM

    I find that my favorite framework is usually the one I'm not currently using :)

    The grass is always greeener...
  • 2 Kurt Wiersma // Apr 12, 2008 at 2:03 PM

    Team Mach II is also having a 2 day training course right before CFObjective in the same hotel. We will be covering not only Mach II but also object orientated programming in CF. Check out the cfobjective site for more info including a detail outline of the material we will be covering.
  • 3 Eric Knipp // Apr 13, 2008 at 11:17 AM

    I still think Mach-II is top dog, simply because it was first, and is more than adequate. It is in danger of becoming too complicated, maybe it is time for the framework to branch into Mach-II lite for smaller apps and Mach-II enterprise for larger ones?
  • 4 Sean Corfield // Apr 13, 2008 at 12:14 PM

    @Eric, Fusebox was first - by several years. Mach-II grew out of Fusebox MX which was an attempt to turn Fusebox into an OO framework back in the CFMX 6.0 days.

    I agree that Mach-II, like most frameworks, gets more and more complex. That was the drive behind Fusebox 5.5 where we created the option to use the framework in a much simpler, convention-based manner. You just write CFCs for "circuits" and .cfm files for display "fuses" and Fusebox automatically wires things together.
  • 5 Kai Tischler // Apr 14, 2008 at 2:33 AM

    When one is contemplating frameworks in the ColdFusion world, yet another framework can
    come to mind: Isaac Dealey's onTap framework, now prominently hosted at Why is it not mentioned here in this thread ?

    And the next question because I am so curious: What about the promised event-driven CF
    framework "Edmund" ? Is it still under construction or has it been retired for whatever
    reason(s) ?

    And now the last question: Does any of the existing frameworks lend itself well for
    integration with Blaze DS or LiveCycle Data Services ? Or is Edmund - or yet another
    framework in the works - tackling this challenging task ?
  • 6 Matt Williams // Apr 14, 2008 at 5:25 AM

    While Mach-II does have a degree of complexity, I would say that you can keep it simple. Just like ColdFusion has a lot of capabilities that aren't used or needed by a lot of developers.
  • 7 Sean Corfield // Apr 14, 2008 at 7:20 AM

    @Kai, Isaac wasn't able to commit to speaking at cf.Objective() so onTap is not part of the schedule. I only listed frameworks for which there are sessions at cf.Objective().

    Edmund is coming along nicely and recently had a substantial amount of new code committed. I will be showing a preview of Edmund at both Scotch on the Rocks and CFUNITED this year as part of my "Event-Driven Programming in ColdFusion" session.

    My feeling for Blaze et al is that integration with the application model is the way to go there which means that the HTML application frameworks (ColdBox, Fusebox, Mach-II, Model-Glue and, yes, onTap) would be less suitable than something like Edmund, along with ColdSpring and Reactor / Transfer.
  • 8 Alan McCollough // Apr 14, 2008 at 8:13 AM

    Complexity indeed! Why is it that as developers we've all heard the mantra about the great developers strive for simplicity, yet our frameworks become more complex instead of more simplistic? Feature bloat? Lack of focus? New for the sake of new?
  • 9 Peter J. Farrell // Apr 15, 2008 at 12:30 AM

    I must admit it that deciding which features to add is a hard line to walk. Not adding certain features because causes the community the become upset because they are repeatedly asked for and they would make development life easier. On the flip side, you add them and then people complain it makes the framework more complex. It's probably virtually impossible to satisfy everybody...

    Most enhancements / features are community driven requests. Such examples include subroutines, SES urls, XML configuration includes, sub/peer applications (modules) and controller level caching.

    One thing we have been doing in recent versions of Mach-II is using "intelligent" defaults which allows you use features with little to no configuration while allowing you the power and flexibility to configure things to your exact needs and specifications. For example, controller-level caching is off by default (meaning you don't even have to use it). It can be configured simply and available to use like this:

    <property name="cache" type="MachII.caching.CachingProperty"/>

    More complex caching schemes are available, but that is the simplest configuration. The new logging features can be configured in a similar manner, but also gives you the flexibility to configure it to your exact specifications. Using SES urls are setup by setting one property.

    I don't know if Alan's comments are directed at Mach-II specifically or just in the general direction of frameworks. However, if somebody feels that we've added things to Mach-II for the sake of being new or that something is bloatware, I'd love to hear *specific examples* so we can improve the framework. Mach-II has striven to become more transparent to the community in recent releases in regards to features / enhancements by releasing specifications and soliciting feedback before any time is spent on code (other than PoC). We welcome everybody to participate by voicing their thoughts / concerns / praise regarding the specifications.

    As for Mach-II lite / enterprise, there isn't much in the framework we force you to use short of a few properties and events at the most basic setup. So I'm not sure the benefit having two version or where to draw the line in the virtual sand what as which features. As for something that needs improvement, I'll be the first to admit that we'll be addressing the page-view section of the XML in Mach-II 2.0 which is probably the most verbose part of the xml configuration file.
  • 10 kilatkyut // Apr 15, 2008 at 12:36 AM

    coldfusion on wheels not a major framework but i like it
  • 11 Alan McCollough // Apr 15, 2008 at 11:05 AM

    My comments aren't directed at Mach-II, rather, they're more of a contemplation of the current state of all the major CF frameworks. Being an old Fusebox 2 veteran, I'm finding it not easy to break out of the old procedural code mindset and fully "get" the OO paradigm.

    In no way am I knocking any of the frameworks, I got nothing but love for all the folks working on Mach-II, MG, FB, etc. Without you folks, I'd still have a wad of CFIFs.

    My experience is that picking up any of the new frameworks requires a fairly signifigant investment in time and understanding. This is, imho, my personal struggle.

    Okay, as to the deep question of "Which is the greatest CF framework?", I would pick Fusebox 3. In my opinion, FB3 offers a balance between simplicity and features. It's been around for years, it's quick to understand. Certainly isn't OO, but if I'm going to slam out a quick app, it's what I use.
  • 12 Sean Corfield // Apr 15, 2008 at 12:15 PM

    @Alan, yes, a lot of long-time Fuseboxers still prefer FB3 but once Fusebox 5.7 can run FB3 apps, I'm hoping that those folks will upgrade and then maybe start to take advantage of the additional power of Fusebox 5.x - including the ability to write Fusebox apps with no XML and no central switch statement: just auto-discovery of circuits and fuse files.

    But each different framework has pros and cons - and appeals in different ways to different people.
  • 13 Mary Jo Sminkey // Apr 15, 2008 at 6:57 PM

    I'll have to admit to still being one of those that really likes FB3....I do get some grief from some people for my software still using it, but aside from the pain and time involved in rewriting the framework for a relatively large application, I find it's not that hard for people fairly new to web applications and ColdFusion to learn, as is the case for many of the people that buy it. Well, many still have trouble getting their heads around it, but it always seemed a good compromise to me for giving you the advantages of a structured framework while still being relatively simple to learn. I am really looking forward to eventually switching to Fusebox 5.5 or 5.7 once I have some more time to work on it, and now that it's going to be a much easier process to migrate. Kudos to the Fusebox team for not forgetting up version 3'ers!
  • 14 Larkin Cunningham // Apr 17, 2008 at 1:52 PM

    Of all the coldfusion frameworks I have tried out, Model-Glue has been the most intuitive. Injecting with coldspring, autowiring, ORM integration, etc, give it great power. I'm using it simply because I could get it working right out of the box and had a lot of frustration trying to get started with Fusebox and Mach-II - so I guess for the impatient among us, MG is the choice. Can't wait for MG3.
  • 15 Allen // Apr 29, 2008 at 2:50 PM

    Wheels seems pretty good for KISS
  • 16 Sean Corfield // Apr 29, 2008 at 2:58 PM

    @kilatkyut, @Allen, as I noted for onTap, cfWheels is not on the list for cf.Objective() which is why it was not listed. Last I looked, development had pretty much stopped on it - have things picked up again recently?
  • 17 Chris Peters // Apr 30, 2008 at 11:26 AM


    Yes, development on ColdFusion on Wheels has picked up again, finally! We release 0.7 beta on April 23.

    Development's probably going to be on halt for a couple months while we write documentation though, unless we discover any major bugs. It's pretty rock solid at the moment though.
  • 18 ike // May 2, 2008 at 9:42 AM

    Ayup! Life conspired to keep me away from cf.Objective this year. And the past month or so I've been pretty busy moving to Boston. Tiff and I have been in town for a month but just got into a long-term apartment yesterday. No furniture or anything yet, just us and our FIOS and an air mattress from Wal-Mart. Though I have started blogging again, and I've been learning about ColdBox and ColdSpring as the prescribed tools for the project I'm working on for the next few months.

    I generally agree with the "it depends" answer and I think what it depends on most is really what a particular group of developers are most comfortable with.

    That being said, I personally haven't found ColdBox and ColdSpring to be as "agile" as I prefer, though I'm still learning. But if I were tasked with managing a project (which hasn't happened but once in my career), and I knew that I would be working with a group of guys who are familiar and comfortable with ColdBox, it certainly wouldn't be my first course of action to make them switch. I'd lay it out in ColdBox and set them to work on it, and if I felt like some of my onTap resources might help (likely), then I'd just insinuate them into ColdBox where and how they seemed most appropriate for specific tasks. SQL Abstraction as an alternative to Reactor springs to mind.
  • 19 ike // Jun 11, 2008 at 10:49 AM

    @Larkin - I find it interesting that you said you found Model-Glue to be the easiest... I personally find the event.addResult() idea somewhat counter-intuitive as a method of indicating an "if" in the controller. I'm continually surprised by how dramatically different people's experiences of the "learning curve" can be. If I were to pick one from "the big 4" to recommend as having a shallow learning curve, I would probably describe it as being a close race between Fusebox and ColdBox (my own not being part of "the big 4" and me being biased about it anyway).

    I spent the better part of the past week working on a project in which I ported Ray Camden's Galleon Forums to the big-4 frameworks, plus my own and wrote a several page article showing side-by-side comparisons of how various tasks are accomplished in each framework. So for example there's a section on "exit navigation" that shows how people generally accomplish it in each framework in spite of the fact that Fusebox is the only one with specific exit-navigation features. More on that at

    That and a couple other events also inspired me to split the ORM portions of my own framework into its own separate project that I'm calling DataFaucet - more on that at
  • 20 Clint // Dec 16, 2009 at 5:15 AM

    Over the years I have used Mach II, Pure MVC, Model Glue, Cairngorm, and Coldbox on customer applications. Without doubt I can say that my favorite is Coldbox because it offered the most power in a way that suits my programming style in the easiest to use and understand package. Mach II and Cairngorm are the hardest to use and understand. Model Glue works but Pure MVC is pretty cool and I like working with it if I have to.