Wow, how time flies!
It’s been about 2.5 years since I started using CodeIgniter, and 18 months since my last progress report. Even though I was clearly wrong on some things, I still get a laugh out of how pleasantly surprised I was at my first exposure to a real framework, and how (or more importantly why) I ever worked without one.
But alas; now seems like as good a time as ever to make what could be my final post on CodeIgniter .
I do not claim to be a PHP ninja by any stretch, but I feel obliged to try and help any up and coming developers who are asking the immortal question – which framework should I choose?
2.5 years ago I was asking that question and my choice was CodeIgniter. Here is my interpretation of the bad, the good and the future for CodeIgniter.
The Library and the API are stale and have cobwebs
You can certainly find some good CodeIgniter libraries around, but the fundamental problem is in the way they are implemented in CI. While all the cool kids and frameworks are using PHP 5.3+, framework agnostic composer packages and namespacing, CI is stuck with a library system (ignoring the getsparks initiative which never really took off) that requires a lot of manual work to get rolling with. And nobody likes manual work.
Writing a native CodeIgniter library which significantly hooks into CI functionality in no way passes the ever-desirable “code reusability” test.
Stagnant development, tough decisions ahead
As pointed out in a post on Phil Sturgeon’s blog (a guy who seems to know his shit), CodeIgniter has some serious, if not insurmountable obstacles to overcome should it ever wish to catch up to the emerging PHP standards.
Significantly, to catch up to the cutting edge frameworks, CI would be unrecognisable from its current state (and hence, not backwards compatible).
Doesn’t work. If you don’t realise the significance right now, in time you will – and if your vast code base is not readily testable, you will be doing these ones:
It still does a decent job
CI still largely does a decent job of solving many common problems, and it’s well documented and supported. For plenty of developers, this is all that matters.
You can start using composer now
Whether you are building new apps with CI or you are maintaining old apps, start using composer now (I outline how easy this is here). At least you can start getting into the practice of dependency management and using and developing project dependencies.
By studying many of the popular packages available you will also start to realise how top notch modern PHP code is written, and start to see some of the shortcomings in CodeIgniter.
CodeIgniter is here to stay – at least for now – and who knows, it might even get on the comeback trail if version 3.0 can really deliver. At the very least, it’s going to continue to solve problems for a lot of developers and be used in existing applications for years to come.
The problem for me is that it is a very long way from the cutting edge, and I see it as a slowly sinking ship. You have to scroll all the way to 24th August 2006 on the PHP release page to get to 5.1.6, which is the minimum requirement for the last stable release of CodeIgniter, 2.1.4.
Depending on your requirements, CI may very well be ok, but for the complex application I would definitely suggest you look at other frameworks, and like many have suggested, Laravel is a worthy modern successor to CodeIgniter and one that I am currently sinking my teeth into.
Perhaps “Developer13″ comment summed it up best in EllisLab’s post which proposes offloading the ownership of CodeIgniter – I couldn’t agree more.
Just put it to rest peacefully! It’s lived a good life.