It’s time to say goodbye to CodeIgniter

I’ve been a massive fan of the MVC programming pattern ever since I was introduced to it 4 or 5 years ago; the one thing that really helped me get to grips with MVC was writing my own core framework. Since then, I’ve been a CodeIgniter advocate – it was my framework of choice and it served me well – I had built my own libraries for authentication, social media integration plus many other “common” tasks and had developed an advanced knowledge of its workings… enough to make easy work of otherwise more time-consuming code tasks.

However in 2015 it’s very much outdated, and with little to no development going on it’s being left for dust. Just some of the things I wish were in CodeIgniter but aren’t (or aren’t implemented very well):

  • Namespacing
  • Scheduling
  • Decent templating
  • Advanced routing
  • Middleware
  • Composer!
  • PSR-2
  • Decent autoloading

With this thought in mind, I went and had a look on what’s on offer today – and why you should try them. After running through as many as I could find, I settled on Laravel as my next learning target. Just a few reasons why:

It’s got namespacing!
Definitely a sore point with CodeIgniter… want a model and controller for the same purpose? Sure, but you can’t call the classes the same thing. Très annoying!

Scheduling
I discovered this one today, but I’ve worked on numerous projects where I’ve had as many as 10 cron jobs configured, because there was no nice way of getting this to work with CodeIgniter. wget was generally your friend.

What Laravel does is actually quite neat (and, for those with Magento experience, similar to Magento). You create a single cron job to point at Artisan with a parameter of schedule:run, then create your jobs in “console commands” – absolute genius. You can even set up scheduled external commands this way, so updating composer automatically on a schedule suddenly becomes really simple!

Decent templating
The Blade templating engine built into Laravel is quite a powerful beast – you can still use PHP code in your views if you really, really want to. My problem with that is that it makes the code quite ugly to read. Working with Blade is a breeze, and I wish I had used something like this a lot sooner.

Advanced routing
Speaks for itself, but what I really like is how easy it is to send different request methods for the same URL to different controller methods (or different controllers entirely).

Middleware
I had never used middleware until last year, but it’s a seriously useful feature for performing actions on every route, or a selection of routes, without having to inject code into route methods all over the place. Maintainability just got better!

Composer
I never really understood the point in Composer. Yes, I was really slow to pick up on this as a developer… quite a big regret. But once I realised how it could benefit me, I’m always looking for ways to speed up project development by using Composer. Since Laravel is built around it, I’ve got to see its power. And I love it!

PSR-2
Coding standards were never really something I came across until the start of 2014. I had developed a clean way of coding that was massively readable and maintainable, but this was through experience. To my surprise it wasn’t much different to PSR-2 – a few changes here and there, but my code follows PSR-2 coding standards now. Laravel will also conform to PSR-2 in v5.1.

PSR-4 autoloading
CodeIgniter’s autoload features were bloody awful! That’s no exaggeration – I don’t miss them. Laravel’s autoloading is great, and I’ve never yet had to worry about getting something loaded in.

There are many more reasons, like the Eloquent ORM being great (in some respects), but the list above are some of the most useful features I’ve come across in Laravel that I’m not used to!

Leave a Reply

Your email address will not be published. Required fields are marked *