A Follow-Up on Kohana 3 & CodeIgniter 2 – The Flip Side

The other day I wrote about my experiences/opinions with Kohana 3 and CodeIgniter 2. I’ve received feedback from both sides of the debate, and want to share some follow up thoughts and some of (IMO) CI2’s downsides.

Shadowhand commented:

…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.

I should say that my basis for opinion on the “instability” of Kohana has been based on its rewrite between versions 2 and 3, and the rapidity in which those major versions came out. IIRC, the 2.3 series (when I first started dabbling with it) was released in the early-mid 2008, and the 3.0.x series started to become available in mid-late 2009. If I had written an app for release with 2.3 in late 2008 and then been faced with a rewrite a year later that would’ve cost quite a bit just in man hours just to learn the framework (again) and figure out a semi-painless way to migrate my existing code to work with a new code base. Not to mention rewriting docs for my users, and so on.

To be completely fair, CodeIgniter 2 has a lot of its own shortcomings. I previously mentioned the procedural helpers, and the fair bit of hacking required (for me) to get it working the way I want (usually involving modules and autoloading, which yes, are a core part of Kohana). Another thing that irks me with CI is how the config items are lumped into one huge array which can make it very difficult at times to ascertain which config file I got a variable from, not to mention the possibility of item name collisions. Usually to get around this I would simply prefix my custom config files with file_configitemname, but that’s not entirely helpful for the core config files.

And please, PLEASE don’t get me started on using “eval()” in the database class. I know it’s a bit of a workaround…and a lot of times I use my own class or Doctrine, but even so..

Stewart commented

…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.

This sums up my feelings pretty well. From what I’ve been able to ascertain (looking through commits on github and such), the API has remained fundamentally the same in the latest series.

And perhaps, for me, that was it. I just want to know there is fundamental stability within the framework itself, without the worry that my code will have to be completely reworked every 12-16 months.

FWIW I do find developing with Kohana quite easy and fun, and if the recent fundamental stability holds out I may be singing a different tune.

I should also take a moment to thank both EllisLab and the Kohana dev team for putting the countless hours into developing these frameworks so I don’t have to! 🙂

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/