Over the past couple of days, I’ve been looking at PHP frameworks for a project. I’ve dug into the PHP MVC world any number of times, and have even used a couple of these frameworks before, but I’ve never been really satisfied with any of them. I’d make a table comparing them, or something, but that’s not really how I work.
Generally, the way I evaluate software is that I just pick something and start using it until I run into a problem that I am not willing to accept or work around, then I move on to something else. Sometimes it takes an hour, sometimes a single project, and sometimes it takes years, but the methodology never changes.
Here’s how it went.
This time around, I started with the Zend Framework. Why? It’s made by the people who work on PHP itself, so I assumed it would be the most idiomatically sound framework for PHP applications. In other words, applications written using Zend would make sense in the context of PHP expertise.
I downloaded it, set it up on my computer, and got started. The setup was easy enough, and the configuration process seemed reasonable. Then I started going through the Quick Start guide, working through the example application. I got to the section on creating a model. When I started really looking at how Zend models work, I decided that the framework requires too much typing, and moved on to other things.
CodeIgniter is a much simpler framework created by EllisLabs. I’ve used it on two other projects, and was vaguely dissatisfied with it, but decided to give it another shot, because I really do appreciate its strengths. My main gripe in the past has been that CodeIgniter models are really DAOs and I’ve been spoiled by Hibernate and ActiveRecord. What’s particularly frustrating is that the documentation is written by someone who doesn’t understand the difference between the DAO pattern and real object-relational modeling, so it’s easy to get the wrong impression of the capabilities of the framework.
CodeIgniter is trivial to set up, and I got as far as creating a new application and implementing some test functionality. The first (minor) disappointment was the fact that CodeIgniter has no built in support for layouts. Fortunately I was able to find a simple workaround on the forums that works quite well.
Then I learned about CodeIgniter’s philosophical stance against the query string. I knew I was in trouble when I read the following in the documentation for the Input library:
Destroys the global GET array. Since CodeIgniter does not utilize GET strings, there is no reason to allow it.
Let me just say, CodeIgniter may not use the GET array, but my application certainly will. Let’s say I’m writing a report that takes parameters like
timeframe. The most sensible way to approach the problem is to include name-value pairs in the URL. Using POST is not an option for reasons of bookmarking alone.
Eliminating the use of parameters in the query string completely is just an awful thing for a framework to do. Given that this is blindingly obvious, lots of people have asked about it on the CodeIgniter forum. There are workarounds that require modifying the core CodeIgniter code (no thanks), but the official word is not good:
It can be fairly polarizing in the forums here, and there are plenty of existing topics to read through, so I’m going to decline to say anything other than it’s the way the framework is designed. CI wants you to use URL segments and have clean, query string free URLs. I understand if that’s not an answer that satisfies you, but I do encourage you to read through the many existing topics on the subject—the workarounds are not very severe nor hard to keep up with across updates. If it’s a feature that’s very important to you and you want to use CI to build your application, you would either need to modify CI (which is one of the great things about open source frameworks) or be willing to work around it with an external solution.
I moved on.
At this point I felt a little stuck, as I thought I was down to PHP ports of Rails. I love Ruby on Rails, but Ruby and PHP are very different languages, and the thought of PHP on Rails brings to mind Samuel Johnson’s most famous quotation:
“Sir, a woman’s preaching is like a dog’s walking on his hind legs. It is not done well; but you are surprised to find it done at all.”
I dismissed CakePHP out of hand, based on minimal involvement in an unpleasant project that used it and lots of complaints about it that I’ve heard second hand. I thought about it for a second, but quickly decided against it.
My next thought was to try out Symfony. I had just started digging into some really scary looking documentation when I received a recommendation for …
Kohana is a fork of CodeIgniter that keeps all the stuff I like and gets rid of some of the dumb stuff (like the GET method problem). It was easy to set up and easy to get started with, so I’m trying to figure out exactly which parts are the good parts and use those. We’ll see how long the relationship lasts.
PHP’s hidden strength
It’s easy to complain about PHP. Look, here’s Jeff Atwood complaining about PHP. He proposes to create something that will replace PHP. I’m all for this project — as an industry, we should constantly be working to improve and replace things, and we should be building great things in case they do wind up becoming popular.
If you’re going to try to replace PHP, you need to figure out what it is about PHP that enables it to maintain its massive market share. Everybody knows about the friendly learning curve and the easy availability of inexpensive hosting. If you want to create your first Web application, PHP is the simplest way to get started.
What’s interesting, though, are the reasons why you see some of the biggest Web sites deployed on PHP. It’s not because developers love it. It starts with the fact that PHP is easy to operationalize at any scale, or at least easier than most other technologies. It doesn’t require an app server, or a virtual machine, or anything that’s outside the realm of basic Unix processes.
What’s more important, though, is that many of the most experienced ops people in the industry who have deployed large scale sites have a PHP background. They understand how PHP works and where it fails. Building that experience on a different stack would take the same thousands of hours that they’ve already invested in learning how PHP scales. It also seems to me that you see less scaling-related drama from PHP-based sites than you see with sites that try newer technologies, or eclectic mixes of technologies. We’ve never seen Facebook go through growing pains like Twitter has gone through.
If you’re working on something with the goal of displacing PHP, the Twelve-Factor App manifesto is not a bad place to start. The other option is to build something that runs on top of the JVM, because there’s a lot of operational expertise in that area as well.
That said, the simplicity of PHP from an operations standpoint and the deep experience with it will make it somewhat difficult to displace PHP from its current position in the industry, no matter how much programmers like to gripe about it.