When Should I Use a Framework?
I guess there are thousands of individual reasons for why and when to move to a code framework such as CodeIgniter or CakePHP. The choice of framework is also just as varied as many frameworks are thriving with their own community of support and fanboys.
However, there is fundamentally one reason for deciding when to use a framework — cost.
Not the dollars and cents cost but the cost in terms of time and effort. The time and effort involved in learning the framework plus the time and effort expended over the life of your project supporting framework upgrades, extending it and finding the inevitable bugs.
If it’s more cost-effective to produce your application on top of a framework than writing the whole environment yourself then it’s time to jump on the framework bandwagon.
Some people fear the framework treadmill because it means you’re investing time in a codebase that you don’t control and may die out tomorrow. However, the same is true of your language of choice.
Therefore, you need to look at the return you’ll receive on your investment in the framework just as you probably did when you selected your language.
How stable is the framework? Who’s behind it? How big is the installed base and how large is the community behind it?
How often do they release updates? Does each new release mean a raft of changes are required or was it well-designed in the first place? A framework is meant to be a skeleton that can be built upon. It should be the means to an end, not the end. However, some frameworks have more flesh than bones.
Does the philosophy fit in with your own? Look inside the code, look at the documentation. Are you comfortable with it? I guarantee you’ll be inside the code at some point.
These are some of the factors I looked at when I reviewed a collection of PHP frameworks. In the end I chose CodeIgniter.
I was at the point in my programming maturity where I had my own classes that I brought to many projects — one for debugging, one for logging, another for database abstraction and another for form processing. I also had other partially completed chunks of code for optimizing web page delivery but every new project required some amount of modification to my codebase.
I even got to the point where I decided I should write my own framework so that all these underlying components would work together seamlessly. Google then showed me the light and I plumped for CodeIgniter. It was fast, lightweight and provided the bare bones I was looking for and nothing more. It was also backed by the people behind Expression Engine and if it was good enough for that CMS it was good enough for me. The documentation was also great with lots of clear examples and it appeared to be an easily extensible environment.
And since I’ve now moved to PHP v5 I’m now taking my first steps with Kohana. I may backtrack to the safety of CodeIgniter’s bosom in the near future but I’ve got a feeling I’ll just stick with Kohana and extend the hell out of it but I admit, the learning curve is way steeper than CodeIgniter.
CodeIgniter is designed to work with PHP v4 and provides maximum compatibility with hosting environments but there are a lot of powerful functions in v5 that makes the production of modern sites far easier. Although it will work with v5 environments it doesn’t take advantage of the new functions which simplifies some of the clever stuff CodeIgniter does under the hood. This is why Kohana appeared plus a few other reasons that are more insignificant to me.
However, Kohana’s community is much smaller and the documentation isn’t on the same level as CodeIgniter’s. The lack of a commercial backer may provide Kohana with a more open-source approach to the project and give it independent control but a little money ploughed into documentation, examples, tutorials and/or ebook development would certainly level the playing field and promote the adoption of Kohana a lot more.