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?
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.
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).
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!!!
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'.
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).
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!
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.
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.
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.
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.