A (fond) farewell to Zend Framework

March 24th, 2012 | by | freesoftware


I’ve been a Zend Framework user for a while. I’ve been using PHP long enough to appreciate the benefits of a good framework, and developed a number of sophisticated applications using ZF, to have grown a certain fondness for it. Although it has a reputation for being difficult to get into, being slow and being overly complicated – not undeserved accusations, if we’re being honest – there is something quite appealing about it. Well, was, for me at least. ZF 1.11 looks like the last version of the framework I will be using.

Why? The simple answer is ZF 2.0. Having been busily built over the past couple of years one way or another, a number of betas have been released and it looks likely to me that an initial release is a few months away. At this point I need to make a decision about my future use of the framework, and I don’t particularly like what I see.

Let’s be quite honest about one thing up-front: I cannot claim to have done any substantial amount of work in ZF 2.0. The criticisms within are all personal opinion based on little more than the most itinerant tinkering.

That said, I actually don’t feel like much of what I’m about to say is unfair, for one simple reason: I have tried to like ZF 2.0. There are of course other PHP frameworks, and I don’t really need to name them, and many of them are initially much nicer to get started on than ZF. Despite all that, I got quite happy with ZF1, and indeed approached ZF2 with the idea that it would take a similar amount of effort to learn to like it. I have attempted to apply that effort. I have failed.

Much of what I think is wrong with ZF2 you can quite obviously see in the ZendSkeleton example application. Now, of course, the example applications for most things are pretty poor: every JS framework has a To-do app, and things are generally chosen to show off the best features of the framework in their most flattering light. That’s actually the first thing that hits me about the skeleton application: it’s deathly, deathly dull, but there’s a pile of code needed to get you to that point. The sheer amount of boilerplate needed to get much further than ‘Hello World’ is incredible, and of truly Java-like proportions.

Generally, I like my frameworks opinionated. I like having a culture, or an ethos, which come through as a set of guiding principles for the developers of both applications using the framework, and the framework itself. And ZF certainly is and was opinionated. I suppose at this point, I find that my opinions differ with theirs too much, and that’s an issue.

The first opinion I would cite is the use of dependency injection. Now, I get DI, truly I do. I even like the idea of it. I can see how it would be useful, and how it could add a heap of value to a project. But there is “useful feature” and then there is “koolaid”, and DI in ZF2 is alarmingly close to the latter. As a case in point, just take a peek at the module config for the skeleton app.

The comment at the top of the file first sent shivers down my spine – “Injecting the plugin broker for controller plugins into the action controller for use by all controllers that extend it” – it’s the kind of enterprise buzzword bingo that again, sorry people, sounds just like a Java app.

And as you progress through what is supposed to be just a bit of config for a simple application, wading past the router config and various pieces of view configuration, you’ll see the thing which just turned me right off – ‘Zend\View\Helper\Doctype’. Seriously? A fragment of view code to manage the doctype? As if this is something you can just change at runtime? “Oh yeah, we built it in HTML5, but I can just downgrade to HTML4 by switch….” sorry, no. Doctype is totally fundamental to the templates you’ve written. This is so far from application config it’s not funny.

Other stuff I can’t abide: the default file tree. Did you think application/controllers/IndexController.php was bad enough? Now you have module/Application/src/Application/Controller/IndexController.php. I do get the reason for this, but again enforced modularisation – ZF1 supported modules too without forcing it.

I know how observers might respond to this: it’s a skeleton app. It’s supposed to be showing a set of best practice, you can cut corners and make things simpler. Except, this isn’t true: there’s already a whole load of corners cut. Just look in the layout; there’s a pile of code at the top of the template. Isn’t the view supposed to be where the code lives?! I would have most of that crap in my Bootstrap.php as-was, I can’t believe people are advocating throwing that in the layout template now (and I’m sure they’re not). But there it is, cluttering up the layout, when it really should be refactored somewhere else.

This is the issue. The skeleton app does a whole heap of things just to do nothing except chuck Twitter bootstrap on screen. I am, of course, willing to be shown how all this up-front investment will pay off in the end – but right now, I really do not see it. The more I look, the more I see things which will just require more and more code to get working – a constant investment throughout the life of a project, without any obvious pay-back for it later. As a rule of thumb, whenever I’ve used a framework before, the skeleton always looks pretty good, but a production app gets entirely more complex and hairy. Things don’t improve, generally, at best they stay as-bad. I would worry that a ZF2 app would just explode into a sea of classes entirely unnavigable by a junior programmer, held together by a DI system so abstract they would have little chance of properly comprehending it.

This is really sad. ZF1 had a number of shortcomings which I thought ZF2 looked on track to tackle – and, in all probability, has tackled. The REST controllers in ZF1 were complete bobbins, and ZF2 looks like it has that right. The Db layer in ZF1 was actually quite good, but ZF2 looks to have improved on it. PHP namespaces are of course ugly as sin and ZF2 embraces them, but they make sense and I could potentially learn to love them. But my gosh, just look at the quickstart. Remember, this is the “get up and running as fast as possible” guide for people who already know the language and just want to get cracking.

What is bad about it? Well, 12.2.2 is the start of the “you’ve already installed it – let’s get coding” section. First item on the todo list? “Create your module”. This involves downloaded the skeleton, copying bits over, and being told all is well. 12.2.3, update the class map for the autoloader, using the correct namespace, ensuring configuration is enabled and being lenient with the autoloading (let’s both you and me pretend we understood what on earth this section was trying to achieve).

12.2.4, create a controller. Oh my god, I don’t want to know what Zend\Stdlib\Dispatchable is there for, or why I might pick a REST controller because the quick start doesn’t cover REST. But no fear, we have a basic controller, it looks like this:


use Zend\Mvc\Controller\ActionController,

class HelloController extends ActionController
   public function worldAction()
        $message = $this->getRequest()->query()->get('message', 'foo');
        return new ViewModel(array('message' => $message));

Unfortunately this reminds me again – I hate to use the J-word – of all the geek Java jokes. Boilerplate object-this and method-other-thing-another-method-that().

I so want to be interested in ZF2, but it’s about as far up the corporate enterprise architecture-astronaut ladder as I have ever seen PHP climb. And honestly, if I wanted to program Java, I’d use Java. And then I’d download Play or Scala and actually enjoy it. But for PHP, no. So, adieu, ZF. It has been nice knowing you.