Choosing a Framework
Everyone seems to be putting in their $0.02 when it comes to choosing a framework, so I thought I’d toss my change as well. It seemed to start with a post by Brian Rinaldi about how Overthinking Your Framework is a Stalling Tactic. He makes some very good points on this, and the often suggested idea of “making an application in each one, just to try them out”. Sean Corfield agrees, emphesizing the important part is making the decision more than anything else. After watching Brian Koteks presentation on framework agnostic model layers I couldn’t agree more on this subject.
So what framework should you use? That question really hasn’t been answered because there is no always true answer. If you want the most popular framework with the most jobs for it, use Fusebox. According to Indeed.com there are more than twice as many fusebox jobs than model-glue and mach-ii combined.
If you’ve never used a framework before, it’s also more intuitive to learn than Mach-II or Model-Glue (in my opinion at least), and with Fusebox 5 much of that same featureset can be incorparated later in one way or another using lexicons. That’s not to say I’m suggesting Fusebox for all situations by any means, but the most used, easiest to learn framework it certainly the obvious first target.
Why did I put Ruby on Rails on this chart? Well I’m sorry, it wasn’t to be cruel. One thing that Coldfusion seems to suffer from isn’t that we don’t have a good framework, but that we aren’t unified under one as Ruby is. Java has a few huge frameworks (and more than a few small ones), but they also have the numbers to support that many. With Coldfusion however, our numbers are so spread out between frameworks that nothing is gaining significantly. Take a closer look at the time when Ruby On Rails surpassed Fusebox for job postings…
At that time (May 2006) roughly 1 in 4 people using Ruby was also using Rails. For Coldfusion it was closer to 1 in 8.
Dig a little deeper into this data and you’ll one glaring statistic in this — 1 in 3 ruby programmers uses a framework! It’s probably much more than this actually, as there are surely jobs comming up with “ruby”. “Ruby programming” vs “Ruby On Rails” gives roughly 3 out of 4 people using rails for instance.
Looking at Coldfusion vs frameworks though, it’s a little more one sided…
We don’t use frameworks; or at least they’re not an important enough to put in a job description. It could also be because no Coldfusion frameworks are so confusing that a CF developer would have a hard time learning them. While both are true, based on some of the frameworks surveys I’ve read the total number of coldfusion developers not using frameworks is decreasing (there is currently a poll in progress at CFFrameworks.com on the subject). Of course the average blog reader is a lot more likely to be using a framework, so this isn’t an accurate picture of the Coldfusion community as a whole. From that graph I’d say maybe 1 in 6 Coldfusion jobs mentions a framework. It’s not a pretty sight seeing all that white space, so if you’re in doubt about whether or not to use a framework, just pick one. 
Oh yeah, and all those comparisons to Ruby? They were just for comparison of the community as a whole. Coldfusion has a larger base of programmers (although you’d never guess it by the general publics perception of Coldfusion), which makes it capable of supporting both a framework and a non-framework community. There are of course times when using a framework is just needlessly complicating things, which CF edges out the framework-driven approaches of just about any language in it’s ease of doing this. It’s also a curse if you never take the time to learn the skills to make the next step. I think John Ashenfelter put it best in his presentation at the Frameworks conference (paraphrased).
The debate between using a framework and not using a framework was over in the rest of the programming world long ago. Frameworks won.
Adam,
I hate to agree with this analysis, but unfortunately, its true. I just left a job that was a coldfusion shop who felt they did not need a framework. Granted, they weren’t really a coldfusion shop and they had no experience with the language whatsoever, but still.
I was speaking to Sean Corfield a few weeks ago about this, I feel like there is 3 types of developers in the coldfusion community. 1: Procedural Developers with no frameworks, 2: “wrapper” style developers with little or no frameworks and incorrect/flawed understanding of development layers, and 3: The OOP savy developer who utilizes community frameworks and understands development layers.
Unfortunately, there are way too many people in 1 and 2…and those of us in 3 could be considered a minority, easily.
[...] – Choosing a framework. 01 [...]
Yeah, and Number 1 and 2 types tend to not be aware of events such as CFUnited or CFEclipse. It’s especially surprising regarding CFUnited because it’s held right here in the DC Metro area and I’ve been interviewing at local companies for jobs.
While I find the facts/stats in this post interesting, I think you’re partially comparing apples and oranges. Ruby (and by extension Rails) is marketed to mid-level programmers and above. It has a (basically) proprietary style of syntax, and does things its own way.
ColdFusion was initially built using the tag based CFML to make it easier for designers to understand. Two of the long running selling points for CF have been 1) it looks enough like HTML that your graphic designers don’t get scared by dealing with CFML, and 2) you can fire it up and just get something _done_ quickly.
Totally different marketing directions.
Additionally, CF has been around a lot longer than Ruby, has it not? From my experience, there are a number of in-house frameworks out there among the ColdFusion shops that wouldn’t pop up under a search for “Model Glue”, but it’s still a framework (albeit not always a well constructed one). Whereas Ruby is still “picking up speed”, and it stands to reason that a budding, small, community would support the same framework (Rails), yes? How many CF shops started out using the “basic web framework” in Ben Forta’s WACK books? I know at least one shop that’s running millions of dollars worth of their business through a huge intranet, 100% of which is based on this same sample framework from Ben’s book.
2 cents, pre-coffee, so it should probably be taken with a few grains of salt.
-nolan
@Derek
Very interesting categories. I think we’re definitely hitting a point where more people are in that #3 category though.
@Nolan
I would agree that in CF you can get something small done more quickly than just about anything out there, but it is usually at the cost of maintainability.
Funny to think that Ruby was started the same year CFML was started up — 1995 i think? Very true about how they evolved though, I hadn’t even heard of Ruby until about 2 years ago, which gave it a lot of momentum on one single application rather than a language as a whole. It was really a best case scenario in that respect.
One thing about home grown frameworks though — it goes against two reasons for using one. You lose out on community involvement — whether that means the community contributing it’s code, pointing out problems or just in a simple mailing list. And #2, it’s not public so you could never look to hire someone with that skillset because it’s all internal. It’s not that these are bad though, and they are a good step, and I’m sure there are a load of amazing internal frameworks, but their help is limited.
I too just came from a company that did not use any framework in particular. There were about 7 years of overlapping mess held together by spaghetti (with marinara…) uggh.. Of course the company-wide perception was that “Cold Fusion Sucks” as a result. Many developers (after trudging through layer after layer of application sludge,) decided that Java was the superior technology. This was mainly because they had the opportunity to start from scratch and alleviate the pain of untangling “bird nests” of cold fusion code to get the simplest things accomplished. What they didn’t realize is that by not implementing a unified framework in java, they only furthered the steady march towards chaos in code for future generations of employees.
As the release engineer and IT operative that normally ended up “dealing” with the various implementations, I saw very quickly how important putting a globally standard methodology in place truly is. It doesn’t just make code pretty, it saves money on many fronts ……
In some cases I think home-grown frameworks are better to have than nothing, but I would agree with Adam, that you’re ultimately defeating the purpose. Also, Home-Grown frameworks have a way of creeping (or evolving,) over time, making the original standard obsolete in short time.