FW/1: Worth a look
I'm betting that Sean Corfield doesn't need me to evangelize his software to garner attention for it. I'm a relative nobody — standing in his shadow, so to speak. But it's good, so I feel compelled to share my experience with you.
Disclaimer
I should start by saying that I am generally pro-framework. They aren't a silver bullet, and each tries to solve some set of common problems in varying ways, so each has its place; but for larger projects, or projects written collaboratively by a larger team, or projects that plan on having a long life-span requiring some level of maintenance, I've found front controller frameworks to be quite useful. Not only that, but specialty frameworks like ColdSpring and Swiz have been incredibly useful and eye-opening to me. I suspect that Transfer would be on that list too, if I'd had time to learn it yet.
So, if you're anti-framework, you may not agree with my reasoning. Or, for that matter, depending on your reasons for being anti-framework, you may really agree with me a lot.
Introduction
FW/1 is a front controller framework whose primary strength, in my opinion, is its simplicity. Too often, framework authors (or authoring teams) get swept up in features that only a percentage of the framework users will use, causing needless bloat for the remaining users. FW/1 seeks to obliterate bloat, and I think it succeeds masterfully.
Why I Love It
I won't drone on and on about how it works. Some documentation is available (and getting better all the time), and the framework itself is only 626 lines of code as of this morning's release — most of it well commented — so if nothing else, you can look at the source to figure things out. But what I will tell you is why I love it.
Due to feature bloat, many other frameworks load lots of extra objects (CFC's) and we have to face facts: Although leaps and bounds have been made in improving object instantiation time with ColdFusion 8 and again with ColdFusion 9, it's still a noticeable detriment to the page load time for the user that spins up the application for the first time since it timed out; and that time scales up with the size and complexity of your application. More events means more config, which means more load time — even if it's spread throughout the application life cycle with lazy loading. To put it bluntly: things are getting better, but they're just not quite there yet. (I'm told Railo has excellent object instantiation times, but don't have any experience to draw on.)
Server.cfc, added in ColdFusion 9, will give us a way to spin up the application before the first user accesses a page, but what it doesn't do is keep the application from timing out. That may not be a problem for a site with hundreds of thousands of users, but for a start-up company, or even just a simple blog application that makes use of a framework, that load time after application timeout can be so freaking annoying. Even though I consider myself pro-framework, that load time is what I would consider my number one complaint about the front controller frameworks I've worked with. On nice hardware with lots of memory and a fast CPU, it may not matter much, but for an independent developer on shared hosting it can be a nightmare. In the past I've written scheduled jobs from two different servers to ping each other and keep the applications from timing out, but that is far from ideal.
All of this griping has just been to make the point of how awesome FW/1's simplicity is. It's 1 object: Application.cfc. For cleanliness and separation purposes, it's written as a base class from which you extend your application's Application.cfc, but for all intents and purposes, you could rename Framework.cfc to Application.cfc and run your application along side it with a few lines of configuration. That's it. When my application starts, it just starts.
Speed is a feature, and FW/1 nails it. In addition, I'm in love with its simplicity. If something's not working quite right — or as is more often the case, if I've misunderstood the order that things run — I can dive right into the code of the framework and figure out why I'm getting an error within a few minutes. There are no sprawling api methods to keep track of; only one data construct: "rc" (request context) which passes form, url, and service-result data between the controller and the view.
No XML. None. Nada. Zilch. I had at one point entertained the idea of writing a Model-Glue plugin, or fork, that would allow configuration to be specified as CFML or as JSON, but I never got around to trying it. Now, with FW/1, I don't have to write any XML.
I've yet to explore the layouts feature, but I know I will, and I'll be happy to have it. I know it can optionally integrate with ColdSpring, and I'm happy about that. And, with a few minor exceptions, that's about all it does. And I'm thrilled about that.
Posted in Frameworks | 3 Responses
Ive used MG since v1 and Transfer since .6 and have loved them both. But using this little framework on top of CFORM is sooooo concise, so pure, so perfect. Its freaks me out.
I'm glad others are checking it out.