I’ve spent a good bit of time in the last few days evaluating PHP Web application frameworks on behalf of my main client. We’ve finished the first phase of a planned large, long-term project without much thought to architecture (because it was a pilot beta and there was no guarantee it would be continued and because we had no idea where we were going at the start). Now it’s time to introduce a real architecture and growth strategy as well as content management support.
As a Python guy, I’d love to choose a Python framework but the client is unwilling to allow this because of the (correct, I suspect) perception that the universe of PHP programmers is much larger than that of Python coders. So Django and Plone are off the table.
In the world of PHP frameworks, I’ve uncovered and done some broad (but not deep) assessments of the following:
(Read more if you want to read a pretty long article outlining my research and my conclusions.)
There are far more similarities among these tools than there are differences from what I can tell after 20 or so hours of investigation during which I’ve read documentation, looked at sample code, Googled to get an idea of community size, and read blog posts and discussion board conversations about the tools, individually and comparatively.
I knew I wanted a framework that implemented MVC (Model-View-Controller) architecture. That implies object orientation, but it doesn’t demand full OO, which in any case is, from a purist’s perspective, not really implemented in PHP any more than it is in C++. Still, the object overlay is adequate and usable.
At the outset, I only knew about symfony. I dug up the others in the course of my evaluation. All but LAMPShade are open source projects. LAMPShade is a commercial undertaking. (CodeIgniter is free and open source but has a company called EllisLabs behind it and features a great-looking CMS tool called ExpressionEngine that is commercial, though reasonably priced).
Nothing I saw in my initial pass through each of these frameworks made one of them stand out as an obvious winner or loser. It seemed like, as is so often the case with these kinds of technologies, the question of personal taste was an overriding factor and that it would be hard to go completely wrong by choosing any of them. So I distilled out of the discussions and articles some questions that are pertinent to my personal taste when it comes to frameworks. Here are those questions and how I ended up answering each one. (And let me say I am eager for folks who know more about these things than I do to challenge my conclusions.)
How Steep is the Initial Learning Curve?
There seemed to be very little argument here. Ranked in increasing order of complexity, the Open Source products ranked:
- Codeigniter
- CakePHP
- symfony
How Good is Documentation?
Documentation has a great many aspects to it, including:
- Published (hard or soft) complete manuals or books
- Searchable online API reference
- User-generated docs such as code snippets, add-ins, etc.
- Tutorials (screencasts and written)
- Sample Sites
In this respect, strangely enough, the newest entrant of the bunch, symfony, scores highest. It has a printed and online full book available. I read six chapters and was pretty impressed with the quality of writing and the coverage. symfony also has a fairly large number of user-contributed plugins and code snippets.
CodeIgniter’s docs are decent but pretty lightweight (just like the framework) and the number of tutorials is pretty limited. In addition the majority of its sample sites (“Projects”) are in non-English languages. Not a knock, but it makes it hard to evaluate what they have and how deep they are.
CakePHP’s documentation is more than adequate and, from the reading I did (six or seven chapters or parts thereof) is quite readable. I loved the API documentation, which not only did a good job of explaining where each object/class fit into the scheme but also identified the line of code on which the object/class definition appears in the CakePHP core source. That feature was missing in the other products’ documentation (or at least wasn’t easy to find).
So I rank the docs as follows, from best to worst (noting that none of them is bad):
- symfony
- CakePHP
- CodeIgniter
(It’s worth noting, too, that you’d probably need fewer docs with CodeIgniter anyway since it is far more lightweight than the others.
How Warm, Welcoming, Helpful & Responsive is the User Community?
I did not join any of the groups. I purused forums and Wikis where they were available, I eavesdropped, I sniffed, and I listened to what people said off-list about the helpfulness of the community to them. My conclusion based on those admittedly limited and unscientific probes ranks these tools from best to worst as follows:
- symfony
- CodeIgniter
- CakePHP
It is perhaps worth noting that I saw a few comments about the relatively unhelpful, RTFM attitude of the CakePHP list and observed some of that myself but I’m not sure the differences between these tools on this point are really all that great in the final analysis. So much of one’s experience with a user community is a function of how one shows up in it.
How Much Code is Automagically Generated?
Stated differently, “How much do I have to know or learn about the framework’s code internals to make my application work?” There are two extremes. At one extreme, the framework auto-generates directory structure and gobs of starting code that give you a big leg up on getting the app working but that later can prove to be a serious obstacle to doing anything outside the box. (This was my experience with Ruby on Rails.) At the other extreme, the framework generates a simple starting point with little or none of its code intertwingled with yours, giving you greater flexibility but perhaps making you work harder to get your app started down the right path.
There’s a lot of debate in this area. My preference, however, is for a framework that leans at least somewhat in the direction of giving me a good start without building a wall I’ll have to climb down the road when I want to do something beyond what the framework (and scaffolding where that’s part of the mix) has envisioned.
My assessment of the frameworks on this issue, from most to least desirable for my purposes turned out to be:
- CodeIgniter
- CakePHP
- symfony
How Complex is the Directory Structure?
This may seem like a replication of the previous point but it’s subtly different, at least in my view. If a framework generated a lot of code and intermixed it with my app code but did so in a way that was clean, elegant and easy to understand, I’d see it as less problematic than one that generated less code but buried it so that simply exploring and understanding it was a major undertaking.
On this basis, I ranked these frameworks as follows:
- CodeIgniter
- CakePHP
- symfony
How Strong and Deep is Template Support?
Interestingly, CodeIgniter includes an extremely lightweight, largely unhelpful templating system and ballyoos the fact that it doesn’t require you to learn a templating language. I don’t consider that a Good Thing; templates make design consistent and easier for folks like myself.
CakePHP, on the other hand, doesn’t include any templating by default at all as far as I can tell. It does, however, have good support for plugging in third-party libraries, presumably including a templating architecture like smarty. But then, presumably, so does CodeIgniter.
Symfony by contrast, includes a full-blown and well-thought-out templating support system.
I rely heavily on templates, particularly in the CMS aspects of my designs. I want users to be able to create new pages from templates which have locked and editable regions defined. It’s not clear to me how hard this will be in CI or in CakePHP.
On this point, then, I’d rank them:
- symfony
- CakePHP
- CodeIgniter
Conclusion
It seems to me that my brief analysis of these three tools has confirmed a long-standing teaching in the world of technology: power is inextricably linked to complexity. The more raw power a framework has — the more it does for you and the more open it is to you manipulating it — the more complex it is. The more complex it is, the steeper the learning curve.
Clearly among these three tools, symfony is the most powerful and complex while CodeIgniter is the most accessible and (apparently at least) less powerful (at least out of the box), while CakePHP is between those extremes, though perhaps closer to symfony than to CodeIgniter.
if I were a first-rate PHP coder, I’d probably be inclined to adopt symfony. But I’m not and I suspect I’d encounter a lot of the same frustration with it that I did with Ruby on Rails when I made a serious run at learning it a year or so ago.
So for me it comes down to a choice between CakePHP and CodeIgniter. As I look back over my ratings above, I conclude:
- CodeIgniter is less complex than CakePHP
- CakePHP has somewhat better documentation than CodeIgniter
- CodeIgniter’s community is slightly more responsive and helpful than CakePHP’s
- The automatic code produced by CodeIgniter is more easily understandable than that generated by CakePHP
- CodeIgniter’s file structure/architecture is more straightforward and simpler than CakePHP’s
- CakePHP’s templating support seems slightly better than CodeIgniter’s, though neither is particularly obviously strong.
On four of six criteria, then, CodeIgniter is superior to CakePHP for my purposes. The facts that:
- It has a company behind it (as does symfony)
- That company offers a CMS solution that looks good and is quite affordable
- Despite its lightweight size, CI comes with a fairly impressive and interesting-sounding set of built-in classes for email, FTP, CAPTCHA and a few other things I know I’ll need.
add to the emerging feeling that I should be leaning toward CodeIgniter.
As I was nearing the end of my evaluation, a strange thing happened. The CodeIgniter Web site went down. In fact, the parent organization’s Web site went out of commission. That didn’t make me feel very good!
My progress toward a final decision is now being held up by codeigniter’s Web site issues, so I’m going to post this tentative conclusion and then focus on CI stuff in subsequent posts. This one’s far too long already!
