In response to Chris Hartjes' "More Framework Fun," aka Why The Zend Framework is a Bad Idea

posted by: Nate

With a few notable exceptions, I tend to avoid speaking publicly about my feelings on the Zend Framework, for reasons which will become clear shortly if they aren't already. However, Chris Hartjes and I were engaged in a discussion about the merits of the Zend Framework vs. CakePHP, which Chris recently blogged about here. While we agreed on most points, and most importantly the conclusion, Chris' post didn't quite capture the central points of my argument, or more likely, I didn't put them across very clearly.

What started off as a follow-up comment to his post quickly turned into a post in it's own right. I know I haven't posted in a while, and a lot has been going on which I need to catch up on / post about, but I promise I'll get to that shortly. For now, without further ado, I give you the crux:


First, I don't think the addition of a console makes Cake any less MVC-oriented. While I could theoretically build non-MVC console-based (obviously) apps off of it, the console tools themselves are ancillary to the actual framework structure, and are primarily designed to assist in tasks focused on building apps off of that structure.

This distinction is important and intentional: the classes and components in the CakePHP core were all designed together, the better to work together (unlike other PHP projects where multiple independent solutions are merely "glued" together in hopes of the best). Not only that, but they were designed to work together within a particular structure and hierarchy. The ability to develop applications quickly derives from this synergy, and the further away from that you move, the more you begin to slide down the slippery slope of becoming Yet Another PHP Component Library.

Second, in terms of comparing Cake to ZF, the ORM layer is important, but it's really secondary to a couple of other factors, specifically the underlying philosophy and core architecture. CakePHP's core architecture is far more developed and vastly superior to the Zend Framework's. I contend that this is a direct result of having a clear definition (or lack thereof) of each project's philosophy, and actually sticking to it (or not, respectively).

While CakePHP has a very solidified, well-defined and focused philosophy, the Zend Framework is based on the mildly-specific-at-best principles of "Extreme Simplicity" and ye olde 80/20 Rule, i.e. "20% of stuff that 80% of people are likely to use" (or is it "80% of the stuff that 20% of people will use"? Someone please correct me, as this is likely a misquote).

The other important point here is that, when it comes to philosophy, we actually stick to our guns. While Cake is very robust and fairly comprehensive, it is still very light compared to most other frameworks or libraries in it's class. The Zend Framework, on the other hand has, as of this writing, core components for Amazon and Flickr web services, a measurement unit conversion component, and an Audioscrobbler component, yet they have no ORM layer. Even the most simple database interaction in the Zend Framework essentially consists of manually writing SQL queries in PHP syntax.

In comparing each framework's size in terms of code and functionality, the Zend Framework is significantly bigger than Cake. Here in the U.S., we are typically of the mind that "bigger is better" (often to our own collective detriment). It logically follows then, that the Zend Framework is more capable, and therefore better. However, as we have seen, not only is it missing key elements of functionality which are highly relevant in the web development arena, but it lacks a clear vision or discernible goals, which is why additional features and components continue to pile up in a seemingly ad-hoc fashion. It has some very spiffy features, to be sure, but as a project lacks the vision or direction to decide what to do with or about all of them. You could say the framework is all dressed up with nowhere to go.

However, even without a specific direction, it seems that the Zend Framework is proceeding rather quickly towards their as-yet-unkown destination. A cursory review shows that they have nearly 200 contributors, with over 100 commits in the past week. So perhaps a more accurate analogy would be to being behind the steering wheel of a Formula 1 racer, only without the steering wheel.

In a good framework, components that provide specific, application-level functionality are ancillary to the framework's core, and for good reason. Suppose you have a web application which you would like to extend by adding an XML API, but your framework of choice does not natively support outputting data as XML (for the record, CakePHP does support XML output). In a well-designed MVC application, it is a simple matter to integrate an external library with your view tier to handle XML output. Such is the importance of a strong core architecture: when an application is provided with structure by default, it is given a solid foundation for expansion. The architecture defines a place within the structure for each element of the application, leading to well-designed, loosely-coupled, agile, maintainable code. Therefore, the question of whether or not a framework supports feature X becomes far less important than the question of how to properly integrate feature X, and how easy it is to do so.

A great (or terrible, depending on how you look at it) thing about developing in PHP is that, for any reasonably well-known technology, one can quite easily find half a dozen PHP packages to integrate it (the fact that these packages may vary significantly in degrees of quality is beyond the scope of this paragraph).

So, the fact that the Zend Framework packages dozens of helpful components which may or may not be useful in any given application doesn't really add a lot of value, since, if it becomes necessary to implement some specific functionality, one could just as easily find several other libraries of equivalent or roughly-equivalent functionality. It's also important to point out that at this stage in the ZF's development, the average PHP library for any given task will likely be more mature than it's ZF counterpart.

For too long, the PHP community has suffered from try-to-make-everybody-happy-itis (which often masks itself as reinvent-the-wheel-to-make-myself-happy-itis). This disease is prevalent in many major PHP projects, i.e. PEAR, but is practically epitomized by the Zend Framework. The result of this disease is, of course, that nobody is really happy, and you end up with a lack-luster, unfocused product.

To summarize: I have, in the preceding paragraphs, clearly laid out criteria for evaluating two frameworks, one against the other. As such, I contend that based on said criteria, choosing CakePHP over the Zend Framework is a measurably and objectively better decision for the vast majority of web applications.

Thanks for reading, and have a nice day. (At least I tried to end on a positive note).