Tuesday, January 18, 2005

Moving away from FuseBox

I've never really been a huge fan of fusebox. I think most of it's benefits have been balanced out by it's problems over the years. With the cfmx component structure beginning to mature, I think it is now time to consider leaving fusebox behind.

I've had the pleasure of working in 3 fusebox shops in the past year. I'm currently in one now, but I'm not on a fusebox project. All three of the shops had implemented something less or different than the standardized fusebox. FuseDoc was used in only one shop, as were XFAs. None of them were even evaluating fusebox 4 yet.

I find some of the benefits claimed by fusebox somewhat dubious:
  • Increased productivity - I haven't really seen huge gains in productivity, even on large projects with thousands of templates. In many instances, I've even seen productivity losses, especially when it comes to debugging. Also fusebox makes the use of some of the productivity aids in Dreamweaver unavailable.
  • Increased code reusability - True, you tend to get greater code reuse than plain old coldFusion would provide without a dedicated strategy to write reusable code. However, components are even better suited to code reuse than fusebox. Not only can the code be reused, but extension provides even greater flexibility by allowing reuse of only parts of existing code.
  • Easier code maintenance - Again, component based architectures seem to have the code maintenance benefits of fusebox beat. By writing components that maintain their encapsulation (by using the variables scope instead of the this scope), changes to components can be made when needed. In many cases code that relies on the component being changed is unaffected by the component modification. Additional functions can be added without disrupting existing dependant code.
  • More productive team development - For some reason, all of the fusebox shops I've been in have been set up in a similar fashion. All the developers work off of a single development server using CFStudio as their editor. Some use source control and some don't (the shop that didn't use source control on a single dev box is just nuts). I like working on my workstation with a dev copy of cf and dreamweaver. That way I don't have to file a 5 part change request to get debugging turned on.
Another issue I have is that I like to use css positioning for laying out my sites. I have had very little success getting fusebox sites to play nice with the css features of Dreamweaver. If you've had better success, please let me know.

Also, running fusebox in a shared environment can be a problem as well.

I'll probably take a look at Mach-II, but I've heard that fuseboxers have trouble understanding it.

Follow-up post


  1. Brilliantly correct, fusebox is more culture than actually a good methodology. It's sad, but we are so into the hype, that we ignore the real issues.

    There should be a global coldfusion standards system, including a generic methodology, but it should be based on common sense and logic, and learning from our mistakes...

    ColdFusion Purist

  2. There are two points that, in fairness, I should mention on the positive side for fusebox.

    1. In a multi-developer environment, fusebox sort of lets you level the productivity of your people. I've seen some really weak developers able to contribute to a project because of the framework.

    Because of the wealth of information about fusebox, you can drop it into a new shop very easily and quickly. You don't have to write your own training manuals or coding standards. All you have to do is buy a few books.

    2. There is some pretty brilliant work under the hood in fusebox. A study of the framework is worth it just from an academic standpoint.

  3. Craig is simply wrong, but that's fine, he's entitled to his opinion. If you care to listen to folks that are far more knowledgable about software development than he is (Sean Corfield, Hal Helms, Barney Boisvert, and many others), they would firmly contest his misperceptions. I find Fusebox very simple, and firmly based on common sense. I could easily go tit for tat with Craig on any of these topics and why Fusebox addresses them very nicely.

    Mike, to address your comments:

    I haven't had any debugging problems, but I don't use Dreamweaver (I hate it), but rather CFEclipse. A few cfdump and cfabort statements, in consort with the CF error information, are usually all one needs.

    CFCs are excellent for handling business logic and creating object models. But you still need some sort of "glue" that handles the overall request. This is the "controller" in MVC. Fusebox is a controller, as is Mach-II. The model is your CFCs, and the view is your display templates.

    Easier maintenance: Mike it seems like perhaps you are missing the fact that you can use CFCs extensively and easily with Fusebox? The two work extremely well together and are by no means at odds with each other. My current project is a massive (70,000+ lines of code) applicaiton using Fusebox 4.1 as the controller with virtually all of the business logic and database interaction handled by CFCs. All of the advantages that you listed of using CFCs are true, and work just fine with Fusebox. If you'd like to see this idea in action, check out the bookstore sample applicaiton at www.briankotek.com for an example of using CFCs with FB 4.1.

    Regarding team development, I'm not sure why you think that working locally to do development has anything to do with Fusebox? We develop locally using a central VSS repository, deploy to a test server using Apache ANT, and finally deploy to the production server also using ANT. This all works seamlessly.

    Regarding the CSS issue, I can't comment because I don't use Dreamweaver. But I have used CSS with Fusebox with great success. In fact I would say that because Fusebox easily allows for the various pieces of content to be generated separately and then aggregated together in a final layout, using something like CSS and DIVs is actually easier.

    Finally I've never had any problems with Fusebox in a shard environment. That should not matter at all. Can you explain this further?

    In the end, Fusebox is meant as a help, not a hinderance. If it's causing you problems, then definitely use something else. I just want to make sure that the problems are real and aren't just a misperception or caused by something which has a simple solution that you might just be overlooking.


    Brian Kotek

  4. Also Mike, Mach-II really uses the same idiom: framework files as the controller, CFCs as the model, and display templates as the view. The biggest difference between FB and Mach-II is that Mach-II *forces* you to use CFCs for the model, while it is optional (but a good idea) with Fusebox.

  5. Brian's already said most of what I was going to say in response. More of my thoughts are on my blog:

    http://www.corfield.org/blog/index.cfm?do=blog.entry&entry=889CCE16-E41E-6972-EBAC9A7C4025CAF9Craig, you want a "generic methodology" and a "global coldfusion standards system" yet you don't seem to want people to standardize on the most popular ColdFusion application framework and its associated methodology. Your argument, as usual, makes no sense whatsoever.

  6. Fusebox utterly sucks. Massive overhead and complication for no reason. Learn to write CF code properly and you won't need a piece of junk like fusebox. The only people who stick up for this crap are the people who can't write normal CF code.

  7. Fusebox is for programmers who doesn't have a strong foundation in programming. In other words, it's something for juniors and intermediates who wants to pretend they can build real applications.