There is an enormous number of PHP frameworks available so I thought I share my experiences working with some of the most popular frameworks for PHP development. I have personally used all of the frameworks I describe either for my own projects or for actual client work. Here are my notes on how I evaluated various PHP frameworks and why I chose the PHP Fat-Free Framework as my PHP framework of choice.
The first PHP framework I used for a real project was CodeIgniter. At the time, it seemed really easy to get started, had great documentation, and an active community. I didn’t want to pick a framework that would die out and then leave me stuck with a client site running a dead framework and CodeIgniter seemed well respected and established. I used CodeIgniter on at least three client projects and several internal projects as well. I became quite familiar with the framework and it had many features that I found extremely helpful.
There were, however, a few things that irritated me when developing projects on CodeIgniter. First, at the time, it was a PHP4 framework. Not that this was a major problem because I could still write my own PHP5 classes and run everything on PHP5. Nevertheless, it was a bit annoying to know that the framework could be so much better under the hood if it would just take advantage of PHP5. This has since been resolved with the release of CodeIgniter 2.0 which now requires PHP 5.1.6 or newer.
The second irksome issue was that the Model in the Model-View-Controller paradigm of CodeIgniter wasn’t really a “model” in the traditional since. CodeIgniter models are all singletons. I like to have the model correspond to a row in a database table where the column names of the table are the properties of the model. In CodeIgniter, however, the Model represents the table as a whole rather than a row in the table. This never really worked well with my coding style or thinking so I ended up designing my own models, thus, not really taking full advantage of what the framework could/should be providing.
After a few projects with CodeIgniter, these quirks got the better of me and I began looking for a new framework.
The next framework I worked with seriously was the Zend Framework. This seemed like a good framework to use because it clearly wasn’t going anywhere since it’s backed by Zend. The community was growing and active and the documentation was relatively good as well. The Zend Framework is a gigantic gorilla of a framework. In fact, many people don’t even refer to it as a framework but rather a PHP library. The Zend Framework has classes to do just about anything you can think of. It’s is purely a PHP5 framework and it did not have the model/singleton issue that I was bothered by with CodeIgniter.
First off, the learning curve for Zend Framework was enormous, especially compared to CodeIgniter. It was not difficult because none of the concepts were new. It was just extremely time consuming because of the size of the framework and the lack of any clear “best practice” tutorials. With the Zend Framework there are bunches of ways to accomplish the same things and I was constantly left wondering if the path I was taking was actually the proper way to be doing what I was trying to do. I felt this way with everything from the bootstrap file to the unit tests. The entire thing was just a mess to work with. Today things are a little better because there are more tutorials online to help guide your through the framework. Be that as it may, if you want to get started with the Zend Framework you need to devote a significant amount of time to bring yourself up to speed on how all the pieces fit together.
Another issue I had was that many of the class names and method names in the Zend Framework are really long. Again, this isn’t really a problem per-se, it’s just annoying. For example, right from the get-go when you set up your bootstrap file you extend ZendApplicationBootstrapBootstrap. Then, to set up your error handlers you access ZendControllerPluginErrorHandler. The long names are mostly due to the fact that the framework is huge with a very large number of classes and the class names denote their location within the directory structure of the framework.
I worked with the Zend Framework for over a year building an electronic medical record system which included SOAP clients and servers, classes to automate email retrieval, and, of course, an MVC web application for interacting with and managing medical records. After wrapping up that project I was interested in exploring frameworks again. Working with the Zend Framework felt like walking through peanut butter. I was ready to see if there was something a little lighter.
Exploring PHP Frameworks
I explored Kohana because it was essentially a PHP5 version of CodeIgniter. Kohana has many new/different features from CodeIgniter, but the general paradigm is quite similar. I liked Kohana, developed an internal project with it, but by this time I had also been developing a Ruby on Rails application and had tinkered about with Sinatra both of which are Ruby frameworks. So, I wanted to see if there was anything more like those Ruby frameworks in the PHP world.
I took a look at CakePHP and also Yii. I preferred Yii, but both of these frameworks were really nice. I did not do any client projects with either framework but I did put together an internal project with Yii. I really liked it a lot. The one big thing that I didn’t like about Yii was that I needed to make a RESTful API for a project I was working on and it wasn’t very easy in Yii to pull that off. Yii would prefer that I use SOAP, which it makes quite easy, but I really didn’t want to go that route. Yii is a really awesome framework though, and if you don’t need a REST API then I certainly recommend giving it a try.
What I really was after, was something more like Ruby’s Sinatra. It’s easy to make a RESTful API, it’s super lightweight and easy to use. So, you might ask, why not just stick with Ruby and use Sinatra? Well, by this time I had begun hiring other folks to work for me. While we do consulting work as well, our primary line of business is WordPress plugin development. My company Reality66 is the company behind the Cart66 WordPress Ecommerce Plugin. We already had a significant in-house library of PHP classes and scripts. The folks on my team are PHP developers, and all our servers are primarily set up to run PHP/MySQL apps. While I personally enjoy learning new languages and frameworks, I didn’t want to have to train my team on a new language and platform. Since we are so heavily invested in WordPress, I’d have to hire folks who were both PHP and Ruby gurus. So if there was a framework that was written in PHP but used the principles of Sinatra then that would be ideal.
As it turns out, there are several Sinatra clones in PHP. The oldest is probably Limonade which has been around since 2009. Oddly, however, it doesn’t seem to have much of a community around it. Likewise, Slim is another “micro” PHP framework without much of a following. Slim looks like a pretty slick framework though. It’s got a nice feature list including RESTful routing. Nevertheless, I kept on looking.
When I came upon the Fat-Free Framework I was immediately intrigued. The entire framework is condensed into a single 55KB file. There is also a library of additional plugins which you can use if you’d like. The Fat-Free Framework, sometimes referred to as F3, includes a RESTful routing engine, views and templates including its own templating markup language, data mappers and a SQL handler for working with databases, and even includes its own unit testing framework. The documentation of reasonably thorough. The framework is under active development and some of the most recent features sometimes out pace the documentation. Be that as it may, the documentation is still very good and since the framework is such a manageable size, you can just read through the source code to figure some things out if the documentation isn’t clear.
I have been working with the Fat-Free Framework now for about a year on and off. Recently I’ve started two new projects that I am building on top of the F3 framework. I plan to write an entire series on how I use the F3 framework including how I organize my application, how I use the F3 testing framework, and will be sharing some of my own PHP classes that I’ve written for use with this awesome framework.
In summary, here are the reasons why I selected the Fat-Free Framework as my framework of choice for PHP projects:
- Very light weight, quick to learn, and easy to use
- Easy to incorporate your own library of PHP classes or other libraries from other frameworks
- Fat-Free Framework is a PHP 5.3 frame work. Takes advantage of the latest and greatest that PHP has to offer – including namespaces!
- Very good documentation
- The framework author listens to the needs of the community and does a great job implementing needed features and fixing bugs.
- Includes a unit testing framework
- Includes a great templating engine. It is an optional feature but helps keep your code organized by reminding you not to write PHP code in your views.
- RESTful routes
- Extremely flexible – organize your code and your application however you like.
- Easy to keep your configuration information separate from you application logic.
- It works the way I expect it to work with very few exceptions.
In my upcoming series on the F3 framework, I’ll be going into more detail on some of these points. In the mean time, I highly encourage you to download the Fat-Free Framework and give it a try.