Code Igniter – PHP Framework

January 4, 2008

This post is in part a follow up to my CakePHP and Flash post but will contain what I hope is useful information for anyone shopping around for a PHP framework. I used both Code Igniter and CakePHP on different projects for different clients and I will preface this post with saying that using CakePHP certainly enriched my Code Iginter experience.

Why CakePHP got the boot -

  1. It took me a while wrap my a head around CakePHP and get ‘comfortable’ with it. I still had to often refer to the user guide but I dismissed it as an investment because I figured the more projects I do with it the better I will become.
  2. “Automagic” is hard to accept. In cake a lot things are reported to happen “automagically” but the cold hard fact is when things go wrong the first suspicions fall on the automagic. Yes you can take another long time to understand the innards of cakephp but the initial learning is already so long WITH automagic that learning the innards could be a time risk.
  3. In the CakePHP and Flash post I outlined some “random things” some of which really are caveats about CakePHP.
  4. I was not in love with their Active Record implementation. I spent enormous amounts of time trying to use it “correctly” and there were so much “little” things that irked me that in the end I hated it. From the naming convention used to return objects from a resultset, to the poor performance queries that may be generated, it is the worst db layer I have had to use in my short career. I am by no means an expert but if you have used EJB3 or some other or/m or active record solution I think you may echo my sentiments.
  5. This project I wasn’t the only server side developer, I was in charge of a team and had I gone the CakePHP route I knew I would have a hard time explaining the automagic that happens (I didn’t quite want to believe it myself), getting everyone to conform the numerous rules in CakePHP, and getting everyone up to speed on some of the caveats and getting other developers to buy into it.

My supervisor asked me to evaluate Code Igniter, and determine whether it was a good solution to use for our PHP development.

Code Igniter (quote from the website) – “CodeIgniter is a powerful PHP framework with a very small footprint, built for PHP coders who need a simple and elegant toolkit to create full-featured web applications. If you’re a developer who lives in the real world of shared hosting accounts and clients with deadlines, and if you’re tired of ponderously large and thoroughly undocumented frameworks“.

I quote the description because I think it is spot on.

Pros:

  1. CI (Code Igniter) is easy to install and migrate from server to server (we also implemented a workflow that made migration a snap). With CakePHP I had some trouble migrating to the client’s server. Maybe I am wasn’t l33t enough but I was really annoyed because you expect migration issues with java projects but PHP, not really.
  2. Very flexible/extensible. I think this is the best pro for me personally. The framework comes with a core set of classes but there are ways to “legally” change core functionality to suite your needs. So when you need to implement some weird functionality that they may not have anticipated, you can do so without getting that feeling of “hacking” things just to get what you want. There are some minor conventions to follow but they do not get into the way of using your own in house coding standards. (unlike cake where you got to name tables in plural and the like, while its a good practice that I insist on still it shouldn’t be necessary because its just another thing for contractors to learn).
  3. CI is Model View Controller based framework (MVC); making it easier to divide and conquer. I think this design pattern was crucial to the success of the project. Because business logic and presentation were separated we were able to divide the work between a number of developer without incident. One set of developer worked on banging out html and css while other developer banged out business logic and then they met in the middle. Queries were put into classes call models which act as the business logics interface to data in the db. This separation made it easier for us to tweak queries and cache data at a later date (which was great considering were were under the gun and tweaking data caching last minute). Had we had a dba the three sets of developers could be working in parallel without stepping on each other toes and thus shortening the time needed to bang out a project (svn and vmware also played a major role in facilitating a workflow that nearly brought tears to my eyes).
  4. Very nice Active Record implementation. There active record classes are easy to use and remember. Even if you are versed enough to write your own queries you can still run it through there active record implementation if it is just to have it automatically escape,quote your data or prefix table names in your query.
  5. Easy to configure and write custom configuration files. This may not be a big deal for some but I think its important for easy migration as well as working with developers with different setups.
  6. Great performance. The site we developed is a community site that is hit pretty hard but I am still impressed by some of the numbers (CI has a benchmark class that outputs execution times).
  7. There are a decent collection of libraries available that should be able to scratch any itch a developer has. We made use of a wide variety of libraries some from Zend framework (Zend Cache, Zend Session and Zend Authentication),Swift Mail and AMFPHP (yes I got AMFPHP working CI such that you can call functions on controllers….. the one thing that gave me the “hack” chills). If you can’t find an example of an implementation of your favorite class CI provides ways to get those worked in without compromising your framework’s upgrade path.

Great documentation. This is always important and the documentation for CI is great. It should also be noted that the framework is really easy to use and it shouldn’t be too hard to wrap your head around. There isn’t too much automagic and if you don’t get something there are forums and other resources to help you out.

Cons:

  1. I believe how data is passed to views could have been handled better. In more complex view structures data could be potentially overwritten and that could be troublesome.
  2. Something about CI doesn’t feel enterprise.  I and a couple  developers  at work  agree that something about CI  doesn’t make us comfortable using  it for major  projects for big  companies.  Maybe  its because  the company that  is behind it appears to be small or maybe its an unfair assessment based on the merits of CI’s competitor Zend framework (which I will be talking about next)
  3. There were some bug/inconsistencies that were somewhat annoying. While bugs should be somewhat expected some of them came at a bad time and at times significantly slowed down the break neck pace of development we were doing.

At the end of the day the CI experience was better than CakePHP and the net impression was good. I still don’t think I would do a major project with CI anymore but it is certainly top pick if you are looking for ease of use and flexibility.

11 Responses

  1. What a nicely written and insightful post. Thanks for both the kind words and honest critique. I’m Technology Architect at EllisLab (the company behind CodeIgniter). If you’d like to discuss any of the bugs or inconsistencies you hit, I’d be more then happy to hear from you.

    Let me also say that I agree that Cake is a very fine piece of work done by a smart group of people.

    Derek

  2. Thanks for the unbiased reviews. Having used Cake and CI this was a fair assessment, and helps when I am rethinking what I should be using. :P

  3. Excellent article. I’m currently searching for a solid PHP framework and CI and Cake seem to come up a lot in my searches. About that “enterprise feel” comment directed towards CI… I kind of see what you mean when you say that… maybe it’s because I got things up and running so quickly (after just the first five sections of the “General Topics” section from the user guide and I pretty much understood how everything worked) with CI right out of the box that my mind went, “enterprise apps shouldn’t be this easy, is this for real?”

    … but it is something I’m curious about because I always have scalability in mind. Would you say Cake would be ideal for enterprise apps and CI for smaller projects or, perceptions aside, would you give CI a “sure, why not” when tackling an enterprise app?

  4. I would say CI is a “sure, why not” over CakePHP, that is based on the assumption that you are going to be working with a team on this enterprise app. CakePHP is kind of hard to get a team up to speed on and the project I used it on choked when it got rushed by a lot of users.

    I think I can now articulate why Zend is more enterprise beyond my “feeling”:

    1) The framework is being touted as part of an ecosystem. So there are more support options for the Zend framework than CI.
    2)Zend is more debugging friendly. CI has error handling but Zend framework’s own is a little richer and gives you more options for catching and gracefully handling errors (and the different types). A big plus for anybody who has done large scale projects in php.

    For medium projects I say give CI a shot. If you are looking to get your team using just one framework then I say go Zend because besides the other pros I mentioned in other posts another benefit popped up with the team I work with and that is the ability to retro fit Zend components into projects that weren’t started in that framework (The loosley coupled thing is really nice)

  5. So would you suggest going with CI for a large PHP project, that would be handling 1 million concurrent users?

  6. For a site with that much concurrent users I would say take the Zend Framework route and save yourself a couple weekends.

    Reasoning

    1) Support
    2) You have the option to subscribe to Zend Platform that may help.
    3) I am only just getting into heavy Zend stuff but I think it would be easier to scale (more so in combination with platform).
    4) I am finding more and more that things I like from CI and Cake are easy to replicate in Zend Framework (though I know not much people would care to hear that) so I am ending up with a boatlaod of cool stuff in ZF.

  7. Dinesh Sharma

    August 15th, 2008

    Thank you for your views. I had thot of going for CakePHP but the installation configuration was cumbersome. Once done the bake is not working. In cakePHP one has to work on command line. After reading your article I think I shud give CI a try.

  8. I’m interested in how you got AMFPHP working so that it can integrate with your CodeIgniter models and controllers. This has been causing me a huge headache. I’ve tried both methods suggested in the CodeIgniter community – using hooks, including a file that tries to instantiate the needed parts of CI – but AS2 doesn’t seem to like either one. What approach did you use?

  9. That was done over a year ago but off the top of my head I can tell you it required some modification of AMFPHP code and I believe some special stuff in the bootstrap. In the end it wasn’t perfect (I ran into a weird bug where booleans were inverted) and I would probably recommend that you check out Zend Framework’s http://framework.zend.com/manual/en/zend.amf.html (it should be able to work without making use of the entire Zend Framework but I am not sure what the path to using this will be)

  10. Great Article!
    Codeigniter is really simple and I used it to build my website. It is great for creating simple web application like content management system, etc. but when it comes to building complex application I can’t guarantee that codeigniter is more powerful enough. CakePHP is best though for building enterprise application.

  11. Must agree with everyone above, great Article.

    We have been using CakePHP for over 3 years and as a result have been able to build a number of large scale web applications. For me, there is some much discussion around which PHP framework to use that it’s just down to picking one and seeing it through. Perseverance is the key!

    For a development team to scale with demand and changing client requirements a framework is a must.

    I am more than happy with CakePHP and have no real reason to look at another. There is definitely a learning curve, and a massive skills shortage of CakePHP developers, however, convention means we can scale a development team overnight and have everyone productive from the start. It makes picking and debugging other developers code really easy. Automagic is one to watch but results in rapid prototyping. The 1.3 release is great and documentation is always improving?

    Big thanks to CakePHP devs and anyone using a framework!

Leave a Reply