What is this Framework for, Anyway?

On the CFCDev list, Barry Beattle just asked several questions trying to understand a badly-written Fusebox 3 app. One of his last questions was "what pain do these actually solve?".

To me, this seems like a really good question. I frequently see discussions on whether frameworks have any value or which frameworks are "best". The first discussion seems to produce a lot of heat with the non-believers saying "That doesn't seem to solve any problem that I have". The second discussion seems to generally resolve with "It depends.".

To the frustration of the person making the inquiry, "It depends." is really the best answer to the "Which framework is best?". After all, if one framework were better than the rest, it stands to reason the rest would fade away.

The real issue is finding the framework that best meets your needs. To address this, cfFrameworks.com has information on most of the available ColdFusion frameworks.

What I haven't seen is a short write-up for each framework describing the problem that it is intended to solve.

I propose that we compile a short description (no more than three sentences) of the problems that each framework was created to solve. That could include a link to more information about that framework.

This would give people a good place to start their search for the framework that is right for them.

If this idea sounds valuable to people, I will volunteer to collect this information from the various framework authors. If cfframeworks.com is willing to host this information, it can be placed there or I can host it myself (clearly, I think cfframeworks.com would be the best place for this information). 

What do you think? 

Comments (Comment Moderation is enabled. Your comment will not appear until approved.)
Steve, I guess it depends on what types of frameworks you are referring to. I mean we do have frameworks for dependency injection and AOP (ColdSpring), for persistence (Reactor,Transfer,ObjectBreeze,DataMgr:) and for architecture (Mach II, Model Glue, FuseBox, ColdBox). Sometimes in the CF world (myself included) we use framework when we mean only the last group and sometimes we mean all of the above (and more). In the case of a framework for architecture, they all inherently solve the same problem of implementing the Model-View-Controller pattern in CF. The rest is just a matter of features and comfort.

Some people advocate switching architectural frameworks depending on the need of the application, which is fine if you are comfortable enough in all of them to do such a thing, but these are not the people asking the question about which framework is best. So, as far as I am concerned, the "it depends" answer isn't "it depends on some quantitative checklist that determines why X framework is best for Y application." It depends, when it comes to choosing an architectural framework, means "It depends ON YOU." Therefore, at best I can tell you why *I* chose a specific framework, but I cannot tell you what framework *you* should choose.
# Posted By Brian Rinaldi | 10/25/06 5:29 PM

I certainly didn't intend to suggest a checklist sort of approach. I find it hard to believe that even limiting ourselves to a discussion of the MVC frameworks that they are all setting out to solve the exact same problem. They must be be brining in some sort of different philosophies or approaches to the problem.

I think a brief overview of the impetus behind the framework is valuable for people trying to decide which (if any) to use. It seems that if they are all aiming for the exact same niche, one would be "better" - it would just be a matter of who had the best implementation. So I tend to believe that they have differences in their approach on a high-level.

In support of that view, I have read statements from framework authors (none that I can now recall) citing differences in philosophy between their framework and another one.

I think that you mention of different kinds of frameworks is also significant. Reading brief introductions for all of them would allow someone to see that some frameworks are meant to solve MVC while others are meant to help with persistence of depenency injection. This would help them see which frameworks solve the problems they want help in solving (and perhaps even help them better think about the sort of problems that need solving).
# Posted By | 10/25/06 5:45 PM
Hi Steve,

Best of luck with this. It was exactly what I was trying to do the other month with a couple of different posts. The question was (within the context of MVC architectural frameworks - M2, MG, FB, CB, etc.) what heuristics would you use to determine the framework choice for a given application or a given developer or a given set of functional and/or non-functional requirements.

The most I was able to get
- Any procedural people on team, consider FB as can do procedural or even mixed development. Doesn't mean you should NOT use FB for OO, just that you can not use MG/M2 for procedural.
- Joe seemed to suggest M2 had more of a java "feel" than MG and I didn't hear Matt, Pete or the others disagree with that.
- Sean has mentioned in the past that for dynamic control flows M2 used to have an edge over MG but (a) not sure if still true and (b) he was suggesting that you'd only need that in a handful of edge cases (I was unable to elicit examples of such edge cases).
- Of course, if you want full stack preconfigured, you want something like MG, but because you don't need to know about CS or use Reactor with Unity (you can not install one and can ignore the other) you cannot say that if you do NOT want full stack you should NOT use Unity.

Other than that best I've got is to play with each one by looking at sample app and then go with whichever makes you feel warm and fuzzy. Always nice to have sophisticated heuristics!!!

Time and time again issue was raised that there isn't THAT much difference in what the frameworks do (within the MVC architectural set - obviously CS is different from Transfer).

That's what I got. Looking forward to whatever you can elicit!!!
# Posted By Peter Bell | 10/25/06 6:48 PM
I think a one paragraph summary of each of the frameworks would be great - and a great addition to cfframeworks.com - when I went there - that is the sort of thing I was expecting to see.

Something else to add may be a learning curve index (1-10?). Fusebox = 1, Mach-ii = 10? Or maybe a small matrix of ease compared to something else... 'If you have X experience than you will find Y familiar and easy to use'.
# Posted By Jim | 10/25/06 7:44 PM
Perhaps the best question to ask of framework authors would be "Why did you build it?".

This may have the best chance at finding out what makes a particular framework special. After all, Mach-II had to be built to do something different than Fusebox because Fusebox already existed. The same thing can be said of MG and all of the rest.

Fusebox seems to get a pass because it was the first ColdFusion framework. Even so, new versions keep coming out and so a reason must exist for that (I would think).
# Posted By | 10/25/06 7:44 PM
Hi Steve,

Great question!!! For example, I wrote LightWire (a proof of concept DI/IoC engine) because ColdSpring was not optimized for DI into transient objects and because it didn't support programmatic config files as an option. Gives a pretty clear sense of the kind of use cases it might fit for as it matures.

Would be very interested to see the same for Transfer, Reactor, M2, MG, etc. Let me know what you find out!
# Posted By Peter Bell | 10/25/06 9:17 PM
Have you looked at my frameworks comparison presentation? [http://corfield.org/articles/frameworks.pdf] It's a little old but it covers the pros and cons of Fusebox, Mach II and Model-Glue (1.x) from the point of view of MVC HTML applications. Hope that helps. I think the MAX frameworks presentation will also help people (if/when that becomes available for public viewing).
# Posted By Sean Corfield | 10/26/06 3:27 AM

That has been on my To-Do list so long, I forgot to actually do it. I will try to review that this week.

I look forward to seeing the Max frameworks presentation as well.
# Posted By | 10/26/06 1:55 PM
Seans frameworks presentation is a great start, but it doesn't really speak to the distinctions between M2 and MG (other than M2's better support for dynamic control flows).

However, Matt said the MAX frameworks session was great and I think there are plans to make that available. I also believe he's planning to work up his thoughts on M2 and where it fits/what it does, so that is going to be great to see.

Then hopefully Joe will do something similar and we may start to get some kind of consensus on relative styles, approaches, use cases and/or suitabiilities for the various frameworks available.
# Posted By Peter Bell | 10/26/06 2:11 PM
In building Fusebox applications, I am a big fan of FLiP (Fusebox Lifecycle Process), and a tool called Adalon. The FLiP development process just makes sense, and Adalon is a modeling and design tool (like Visio) that allows you to create a map of your site. In my mind, this separates Fusebox from the rest of the frameworks.

Every time I come up with a new idea for a web application or website, I fire up Adalon and I start building the wireframe to get my ideas onto the screen and see if they donâ??t just make sense in my head. Within 30 minutes I get a basic wireframe up and then over the next week or two every time I get a new idea I switch into Adalon and I add my idea to the wireframe. Once you are finished with the wireframe, Adalon can generate both code and documentation for your system.
# Posted By | 11/1/06 10:26 PM

I like FLiP as well. It is very close to the process that I follow now. I have heard good things about Adalon as well.

Keep in mind, however, that nothing about FLiP required Fusebox. Anyone can use that process whether or not they use FLiP. Similarly, I don't think anything about Adalon would prevent someone from taking advantage of much of its functionality even if they aren't using Fusebox.

I'm not trying to say anything bad about Fusebox - just pointing out that those are not necessarily advantages that Fusebox has over other Frameworks.
# Posted By | 11/2/06 2:26 PM
This is a very good thing to talk about such a themes. Iâ??m very glad to read it.
# Posted By Betty | 8/2/07 8:37 PM
BlogCFC was created by Raymond Camden. This blog is running version 5.8.001.