Choosing a PHP framework

Back in 2007 I was tasked with evaluating php frameworks and making a recommendation for which framework to become the new standard for building web apps at a previous employer.
The major contenders at the time were: CakePHP, CodeIgniter, Symfony, Zend, and (re-)writing our own in house framework.
Before looking closer at any of the possible solutions, I wrote a set of requirements based on what I thought was most important for a growing company with programmers of very different skill levels and experience.


  • Reduce chore of writing boilerplate code
  • Enable us to spend more time on architecture, user workflow/interaction design and business logic
  • Real prototyping - as in prototypes you throw away when you are ready to build the real product
  • Let every developer regardless of skill level do interesting work
  • Make it easy to create reusable code
  • Reduce developer burn out by having a common standard so developers could switch between different projects easily

The developers at the company had very diverse backgrounds, from software engineering to bedroom web hacking. Up until this point most of the projects had been done either by a single developer or as a team of two, and management had expressed interest in increasing team sizes for projects and implement a "revolving" team in order to reduce burn out.
The main application of the framework was for developing a large integrated web app based on smaller modular apps. It would also be used for developing small one-off custom apps and sites.
The production environment was a Debian based LAMP setup, partially maintained by the hosting company.
The development environment used was based on XAMPP with ZendStudio as the IDE and Subversion for SCM.
Our own custom framework
We had a simple PHP5 based framework, written by a single developer with little time for testing and "designed" with little regard for actual use by others. It mixed and matched business logic with presentation and was as far  from DRY as you could get.

  • Can be tailored exactly to our needs


  • No existing documentation
  • Full burden of maintenance
  • Must spend significant amount of time on developing the framework before we can really focus on the apps
  • No real in-house expertise in developing scalable php frameworks

CakePHP is a wholly Ruby on Rails inspired framework, designed around agile principles like DRY and Convention Over Configuration.

  • Solid MVC architecture
  • Sound app foundation
  • Bake (Automatic code generation)


  • Poor documentation at the time.
    (The documentation after the 1.2 release has improved so much it is now among the very best out there)
  • Most example code was in the CakePHP 1.1 style at the time.
    (The release of the CookBook and publishing of 1.2 based articles on The Bakery has changed that completely)
  • Rigid structure
  • Limited utility code at the time
    (The current CakePHP 1.2 core behaviors and utility libraries cover most of the things we were missing)

CodeIgniter is small and lightweight, bordering more on the side of library then framework. It aims to provide fast functions with as little configuration and overhead as possible and to generally stay as much out of your way as possible.

  • Light weight and fast
  • Easy to learn for php spagetti coders
  • Very flexible
  • Optional MVC


  • Very little utility code (at the time)

Originating as a fork of Mojavi3, Symfony has taken inspiration form Ruby on Rails for many features and integrated other existing PHP open source projects for some of it's features. It has a clean design and follows agile principles like DRY and KISS.

  • Solid MVC
  • Decent documentation
  • Good range of built-in utility code


  • Unsual coding style in views (<?php ?> for every line or php statement)
  • Very rigid app stucture (at the time)

Zend Framework
Zend framework is an enterprise oriented framework designed "with simplicity in mind. To provide a lightweight, loosely-coupled component library simplified to provide 4/5s of the functionality everyone needs and that lets you customize the other 20% to meet your specific business needs."

  • Documentation (sometimes a little too good - e.g. documented features had not yet been implemented)
  • Lots of esoteric/enterprisey utility code
  • Very flexible
  • Highly visible and well known commercially
  • Optional MVC


  • Feels and acts more like a library of functions than an integrated framework
  • No real app foundation - you get to decide what constitutes an app
  • No help with boilerplate code

As soon as I had written a small test app in CakePHP and read the code for some of the larger open source apps based on it, it became clear to me that CakePHP would best meet the most critical of our needs. In particular its "convention over configuration" philosophy and console baking functionality would help us make our programs conform to a common standard regardless of individual developer preferences and habits.
Before adopting CakePHP as our framework, the management wanted input from the rest of the developers on which framework they thought was best: CakePHP or Zend Framework.
The result was 5 votes for Zend vs 2 votes for CakePHP. After some discussion, taking into account the arguments for and against the two options, the decision was made - CakePHP would become our standard.
After a fairly long in house training period, including feedback and assistance from the core CakePHP team, we managed to develop some nice apps and publish these articles on the Bakery:

Since then most of the frameworks have matured and improved and some new have arrived on the scene, but I still feel CakePHP was the right choice in our situation. For those who are looking to try CakePHP, I would like to give this advice: Leave your preconceptions and old ways behind and approach CakePHP with an open mind. The initial learning curve can be steep, but once you internalize the conventions of CakePHP, you may find yourself wondering how you ever got anything done before!