Kohana 3 & CodeIgniter 2

For the last month or so I’ve been developing an app side-by-side with Kohana 3 and CodeIgniter 2 to see which framework fits my programming style better. Nothing terribly fancy; just a simple CMS.

I’ve been using frameworks to develop since 2006, back around CI 1.5.x. The differences between CI 1.7.x (the latest version as of this post) and CI 2.0 are negligible. My biggest nitpick comes with the helpers. I’m lazy and I’m also somewhat speed-conscious, which means I either need to autoload all the helpers my app needs in the autoload.php file (or early in my app) to appease my laziness, or load them as needed to appease my speed-consciousness. It irritates me that they’re basically files holding groups of procedural functions and if I want to access the CI super global I have to instantiate it in every function.

I started dabbling with Kohana a couple of years ago, in the 2.3.x era. I really loved their use of static functions (I’d only had basic OOP experience at the point), but I just never felt comfortable with the way things changed so much between versions. Last year when v3 was announced I had a look through the code and said “forget it”. But eventually I became curious again and started learning it to see how easy/hard it was to develop with it. I personally did not have a lot of trouble learning Kohana 3, between the user guide and the unofficial wiki. Perhaps my biggest stumbling block came with the Database module, which was a complete change from any of the v2.x database classes.

I really didn’t find either framework harder than the other to code for. I was able to more or less figure out how to do what I wanted to do in both. Yes, Kohana’s docs suck and CI’s are much better. For me it wasn’t much of an issue.

In the end it comes down to framework stability for me. And in this case, CI wins, hands down. Don’t get me wrong; Kohana is beautifully written and introduced me to a prime example of clean, well commented code. The devs are extremely intelligent and more talented than I’ll probably ever be. CI is also very clean, though there’s a bit more hacking involved for me to get it to work the way I like. However, I don’t want to be writing my own clean, well-commented code for one version of a framework only to find out the next version is going to totally break backwards compatibility. The lead Kohana devs have stated that there are no guarantees of stability between major versions (ie 1.x-2.x, etc). Comments like “well if it ain’t broke, don’t fix it” are dandy, but if part of the reason I’m using a framework is to let someone else worry about the basics for me, why would I stick with something that is no longer actively developed because the devs are on version 342.x?

While I respect progress and not letting code stagnate there’s something to be said for code stability when you’re maintaining a framework. Uber-optimising something is great (as there are repeated mentions of “x function is faster than w function” in the Kohana forums) but if it’s only saving me 0.02 ms of page load time or 0.25 mb memory, I’m not sure unstable code is worth that bit of extra speed. Furthermore, using an older codebase when you’re a one-(wo)man show can be a nightmare, since it’s a lot easier for one person to miss something than two, whether it’s a simple invalid method call or a glaring security hole.

I want to create apps to earn a living and I want to know that my code will stay more or less relevant between framework versions. API changes are to be expected between versions but complete rewrites, with very little thought for BC is just poor project management, IMO.

Please bear in mind that these are simply my views on the frameworks and my experiences and since I’m not a BDFL PHP guru (or something), you should perform your own research to see what works for you.

Update: I’ve posted a follow up post with some more thoughts (and such): https://nerdmom.wordpress.com/2010/08/31/a-follow-up-on-kohana-3-codeigniter-2-the-flip-side/

Leave a comment


  1. I totally agree. I’m playing around with both K3 and CI2, and my favorite is still CI2, even though K2 is über sexy as well. The community behind CI (and their well-done documentation) is also a big plus for me!

    Great read. Big ups!

  2. “no guarantees of stability between versions”

    Actually this is missing the word “major”, as in “no guarantees of stability between _major_ versions”. This is typical of pretty much all programming tools. For example, look at Python right now… they have been on the 2.x series for a long time and 3.x is not backward compatible.

    I will be the first to admit that Kohana has had development instability in the past, but 3.x is rock solid and has a real release process in place. Please help us by judging 3.x separately from other versions.

    • Jen

       /  August 31, 2010

      Agreed, I did mean “major” versions, and will correct this in my post.

  3. Stewart

     /  August 31, 2010

    Stability is good, but CI is just ridiculous, their “stability” has resulted in them being left behind by other frameworks in terms of features (even basic features like proper autoloading), performance, ease of use, etc. It has also resulted in the community filling in for them with bug fixes, unoffical classes to produce basic features like modulization, neither of which is good (or indeed stable) from my point of view. CI obvioulsy missed the memo that all offical support for PHP4 ended in 2008…

    I don’t see a problem with Kohana making the big change to KO3, I do have a problem with how they went about it (they should of made it clear KO2 had no future, rather than stringing people on and a new version number doesn’t really make it clear it is really a new framework. However they do seem to have at least stopped breaking the API every month which is what happened at some point in KO2, I’ve used KO3.01 to 3.07 for the last 10 months with no problem. As I’ve found KO3 to be superior in virtually every way to CI 1.7.x it really has been a very easy choice.

  4. Kohana doesn’t brake between versions; the major version change (3.0) was a complete rewrite and it just made sense to have it not compatible with previous versions.

    Maintenance versions that are currently under active development (3.0.x and 3.1.x) are backward compatible with the corresponding minor versions (e.g. 3.1.2 with 3.1.0) and there won’t be any API incompatible changes.

  5. For me, CI will always win – the documentation and community are HUGE benefits.

  6. Loves CI. It is stable and the user guide is Amazing.

  1. Top 7 PHP Frameworks | Devlounge

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: