Why should you use a framework?
Several months ago I decided that I wanted to learn a CF framework and use it for an application I was working on. Not for any particular reason other than I've always heard a lot about the various frameworks and decided it was time to learn one.
Since then I've really started getting into Mach-II. It's the first framework I tried, and everything just seemed to "click" with me. I do plan on giving the other frameworks a try in the near future to see what they have to offer as well.
In my case, I started using a framework simply because it was something I wanted to do. But now I'd like to compile a list of reasons for using a CF framework, especially for a large application. I'm not talking about any specific framework, just frameworks in general. I realize that in many cases some of the features of a framework may actually dictate why you use it, but I'm thinking more in terms of using any framework vs. not using a framework at all.
So far I've come up with: code reuse; reduced development time; easier application maintenance; promotes consistent coding; better (more consistent?) foundation for creating an application;
I would love to get the CF community's opinion on why you should (or shouldn't) use a CF framework. What are the reasons/benefits?
How would you finish this statement, "I (do/do not) use a CF framework because..."?
I am pro-framework but the main con I've run up against is the weight of the framework. Some frameworks can be a bit heavy and, depending on how well they're used, can slow down an application or hinder its performance.
http://www.coldfusionguy.com/ColdFusion/blog/index...
A common mistake is falling into the trap of qualifying every development approach as being "with-framework" or "without-framework". Software development, even web development, is a complicated beast with lots of shades of gray between one end and the other.
In any case, I do have a comment, more like an anecdote, about the use of frameworks on large enterprise applications. A while ago I worked for this company that had a really massive beast of a CF product that was implemented with Fusebox. Now, as is very common for enterprise apps, this application had been in production and constant development for a very long time, the result was that you could take different sections and subsystems of this application and you could find all the different flavors, versions and perversions of Fusebox. The moral of the story is that even if you stick to one framework there is absolutely no guarantee that you will avoid the same issues that motivated you to use a framework in the first place.
You can write a bad application using a framework and you can write a bad application without using a framework. In the end, hopefully a framework will:
a) Reduce the amount of time reinventing the wheel for common plumbing
b) Allow you to take that time and spend it making your application better
c) Allow new people (or remind you) to easily know how your application is constructed.
Also, the concept that frameworks are only good for small applications is complete hogwash (sorry to respectively disagree with your Aaron). I've seen large applications that are implemented perfectly using a framework and I've seen large application implemented horribly without one. Same applies vice versa. A framework is a single tool in a box of many tools -- you have to know how to wield it and small problems that you may not know exists in small applications just get amplified as your traffic increases.
The real caveat is that as an application grows -- the problems with how you designed it grow exponentially as well. It's really easy to think that "oh, it's due to a framework", but in all reality it's usually not the framework getting in the way. I'll invoke the "it depends" argument here -- some types of frameworks (i.e ORMs are a good example) are way more complicated that say the MVC package in Mach-II.
Take this example, one application I worked was running 2-3 *seconds* per request (not including HTTP request roundtrip). One developer immediate started pointing the finger at Mach-II until I suggested we profile some typical requests (using the Mach-II debugging output in the logging package ironically). Low and behold it wasn't the framework itself, it was the framework waiting for data from the database. After some performance tuning on the SQL statements and the addition of some missing indexes, the application was running sub 250ms per request. We did a bit of caching (using the Mach-II caching package) for some data that was just ripe on the wine for caching and the average request went to 5-10ms.
Another application performed great in development and staging, but typically requests had a total of about 4 seconds of HTTP roundtrip. Using YSlow, we were able to identify some basic issues performance issues with total number of JS / CSS files, JS not being compressed, poorly optimized images, no far-future expiry headers, no gzip specific file types, etc. Most things were fixed by changing our build process, implementing things like far-future expiry headers for JS / CSS (a few changes to code were made here) and adding gzip / etags on the webserver. We took a 450k page with 40 http requests down to a manageable 115k package and even way less with a primed cache in the browser. The average HTTP roundtrip time for totaled under 1 second and we didn't really touch CFML code here (we only added code to make sure JS / CSS files were served with a last changed timestamp in the URL as so to trigger a re-download if the asset changed because of the far future expiry header).
I guess I should just summarize by saying that there are so many places that it's easy for us as developers to overlook when it comes to optimizing our applications. I guess I just wouldn't put framework at the top of that list to double check. I hope I've illustrated this point with the examples above.
As much as I admire the frameworks and their authors, I have never used them at my job because I have a hard enough time keeping CF alive as is (I'm pretty much the Last of the Mohicans). By throwing in a framework or two I guess I could add an extra layer of learning curve complexity, thus ensuring some job security. For now, I don't see the need.
I don't currently code in my spare time, but if I did that is when I would take the time to learn a new framework. I've always wanted to toy around with ColdBox and Transfer on top of Railo, personally. I think ColdBox is coming out with a print book soon.