Future of Fusebox framework

Question

Good old Fusebox was my first framework and I still really like it. Started with PHP version, currently using latest CFML version.

But time goes by and I'm wondering: maybe I should switch to another framework? Well, I don't want to start holy war here. I just want to know the pros and cons of continuing using FB.

Say, I think that no-XML controllers is very good idea and step into the future. Or maybe I am wrong and it is not enogh and I should concentrate on Mach-II or maybe Model-Glue or ... (enter your favourite)?

But what about PHP? Seems that it has stuck in past a bit. Symfony, CakePHP, Zend etc look much better now and growing fast.

So, a rough list of comparison aspects is following:

1. Time spent for development and maintenance. For me FB seems good enough here.
2. ORM integration. Currently I am using own components (btw, was surprised to see very similar syntax in cf9 previews), but having concerns about their performance.
3. Overall application performance. Caching? "Parsed" files are still good enough?
4. Integration with other products. For example, with unit testing tools -- does anyone has experience of this?

Any thoughts and opinions are appreciated. Thanks.

Answer 1

Fusebox is still under active development and just recently changed hands so the lead developer is now Adam Haskell.

Should you switch to another framework?

That's a subjective question. The only good answer is that -- given infinite time and opportunity -- you should try them all and see what you prefer. They all have their pros and cons, but most people agree that it's not a question of which framework as much as a question of to framework. You're already decided that it's a tool you want on your belt, so good for you. Make it a tool you understand and enjoy.

That said, time and opportunity are not always available. In that case, you're probably best off sticking with what you know and learning what's new with the latest changes to Fusebox. I don't have time to learn them all myself, so I have been a Model-Glue guy myself. I see some Fusebox in my near future, but again, it's subjective and what matters is that you're doing what works best in your situation.

PHP

I can't really speak to the status of PHP frameworks as I'm a CFML developer. Again, if you have the time, play with them and evaluate where they're at and whether they are a tool you're interested in using.

ORM Integration

I know Model-Glue has ORM integration -- Reactor and Transfer both hook in very easily. I suspect the same can be said for Mach-II, and probably Fusebox but I'm not positive about either.

ColdFusion 9's baked in Hibernate will probably work nicely in any framework, but that's yet to be seen.

Performance / Caching; Parsed files?

That's more of a ColdFusion vs. .Net question, right? PHP is a "parsed" language as well. Pre-compiled binary code will always have at least a slight advantage in run-time, but consider that for most web applications adding some more capable hardware is easier and less expensive than spending an extra few months (or more) developing the software.

Are "parsed" files still good enough? Yes! Heck yes!

Integration & Test Frameworks

There are multiple testing frameworks, including CFUnit, CFCUnit, and MXUnit off the top of my head for unit testing (which work well for TDD), and CFSpec for BDD. I'm sure there are plenty of others, too.

CF8 brought integration with .Net, and Exchange (and probably a few other things I'm forgetting), and we've had integration with Java since version 6. It's never been easier to "mash-up" some components written in these various languages to get the best of all worlds.

Conclusion

Your question title is about the future of the Fusebox framework, and I can tell you that it's not going anywhere (except to continue growing and improving, like the other CFML frameworks...). If you're happy with Fusebox, there may be no reason to leave it. That doesn't mean you shouldn't try everything, but there's no reason to abandon ship.

Answer 2

It can't hurt to expand your horizons:

The range of comparison is so vast that you cannot possibly get a comprehensive and precisely-tailored answer to your four criteria in a single SO thread. It's a good question, but one for which no single answer will be definitive.

Instead, I would ask what (if anything) will prevent you from trying a different framework and expanding your horizons (assuming your exclusive or primary experience has been with FB).

Nothing will surpass your own evaluation of your four criteria from first-hand experience, especially since you ask about factors that are either very subjective or reasonably addressed by every "high profile" web application framework out there.

A nod to FB in particular:

The Fusebox framework originated and gained momentum even before most people had heard of XML, or web frameworks. It was one of the first "annoyance busting" web development frameworks designed to actually make web-app development more "fun" (with the goal of removing some of the annoyances and tedium from ColdFusion, which itself was an exceptional framework for its time).

Consequently, it has come a long way and has a relatively robust track record (just like ColdFusion).

This, however, can be considered by some to be a significant detriment against FB (just as for ColdFusion). There is a lot of "baggage" in the framework that quite frankly would not be there if it were the same age as many of the other MVC frameworks that are gaining credibility as the "new kids" on the block. There are many aspects that (from a language design standpoint) reveal some rough-edges that could negatively influence your way of thinking about web application frameworks if you choose FB as your exclusive way of getting things done.

Without naming names, (you've already heard them) I would suggest you would do well to keep FB on your toolbelt, but also branch off into the newer frameworks, especially those that are based on programming languages other than PHP and ColdFusion.

That way, you will also expand your horizons and understanding as a programmer in general.

Answer 3

if you're looking for an all in one Rails type framework, check out cfwheels.

http://www.cfwheels.com

Answer 4

At work we use Fusebox (php)... IT SUCKS!!

If at all possible, I would definately suggest migrating a more "hip" framework.

Although.. What I do, and this seems to aleviate most of my beef with the framework, is to write template files, include that from the switch, and also calculate any "run time" parameters inside that same case statement as well. That promotes good code reuse.

But I mean.. having 1 huge switch statement? Isnt that a code smell for "this should be an object?". It reminds me of a procedural version of a RoR controller class. (I am not a RoR guy..just saying)

Answer 5

Keep in mind your existing code base. I'm very happy with Fusebox but beside that point, I wouldn't change largely because of the existing code base I have built up over the years.

Answer 6

I used FB almost exclusively in my last job. Most of our code base was non-OO (cfc's did not exist yet) so the model/view distinction really helped us. Designers knew to head right to the view folder and not to poke around too much in other places. Circuits gave us a better way of mapping site areas than simply using directories. Generally it solved a lot of problems with the page as construct way of working.

Over time I find that most of the model/controller code ends up in cfc's and dao's with only view files, and indexes really remaining in .cfm so this separation happens almost naturally. This gives rise to a new kind of problem which FB does not really help with - managing all of the cfc's and resulting objects plus initialization and inheritance. Because of this I have started using the coldspring framework which feels a lot more focused on the kind of problems that crop up in modern OO CF as apposed to the page based CF we were writing years ago.

Answer 7

After some time we can say that Fusebox is more dead than alive.

1. FuseNG Update by A.Haskell

2. Status of FuseNG at Google Groups.