There are a lot of sites out there that benchmark frameworks. Every time there is a new benchmark, there is a huge outcry from the loosing sides followers. To date there has not been anything that I know of that has not been bias or meaningful, as the person doing the benchmarking does not know each of the frameworks and its normally a 'hello world' application which is completely pointless as I could just do echo 'hello world'; and be done with it.

I have been thinking about this for a while and the one thing that does not seem to be covered which imho is far more important than a few nano seconds here and there. What is it like to develop applications using said framework.

What I will be doing is, over the next while as I find blog posts about other frameworks is try and compare the same bits of code in CakePHP as close as I can so that you can compare them from that point of view. Amount of code vs functionality gained, not the usual requests per second.

First up is Zend Framework, and custom View classes. There is also a question on StackOverflow that lists 6 points to making your custom View class work on Zend. The advantages that you will see here are due to cakes convention over configuration paradigm. Although it can be harder to grasp for "noobs", in the long run its so much more civilized.

The points listed for Zend are as follows:

• Extend Zend_View
• Put your method in this extended class
• Instantiate the class (in your bootstrap for instance)
• Assign it to the ViewRenderer
• Pass that view renderer to Zend_Controller_Action_Helper Broker's addHelper method
• Use it in your view

Convert that into CakePHP:

• Create the view file in app/views or app/plugins/<plugin_name>/views
• Set the controller property 'view' to the corresponding files name anytime before render is called.
• There is no step 3

Based on the docs for Kohana:

• Create the view file in the views folder
• Initiate the view $view = new View('my_view');
• Use said view

Zend

In Zend you are having to do this all manually (in the bootstrap...) so you have the added advantage of being able to put the files where ever you like. But is that really an advantage? If you enjoy taking over a mess of a project and having to search through mounted file systems looking for code, sure. If you want to open a folder and find the view class first time, then its not.

You may argue that a skilled Zend coder will know where the files are, but if they were to walk into a project without having seen it before, the first few days will be hell. Coming from any other environment as a seasoned Php developer you will have loads of issues as things are being done in places that would not seem obvious, like loading views in the bootstrap.

What's wrong with doing this in the bootstrap you ask? What about all the methods that just redirect, like after a save. There is no view, nothing to render. But you have still included and initialized that class adding it to some object that is eating up your memory and adding a few nano seconds to each request.

The other point to make is the amount of typing. Its normally the first thing I hear when talking to other developers about Zend. Zend coders must go through keyboards like there is no tomorrow. Having to call and include classes like Zend_Service_DeveloperGarden_Response_LocalSearch_LocalSearchResponse, im all for being verbose in the naming of classes and functions but this is a whole new level.

Kohana

Kohana almost got this right. Only problem being is that the view can be used directly in the controller. You just did $view = new View(...); in your controller and can now do what ever you want with it... in the controller. We are still using an MVC framework, right?Direct quote from their manual, 'views themselves can contain code used for displaying the data you pass into them. For example, looping through an array of product information and display each one on a new table row.'

Obviously this is not a requirement, but its just to easy to make the mistake. Next thing you know you are debugging a 3000 line controller with database calls and view methods all in the same method.

The other issue I have with Kohana is the number of ways there is to set data for the view. There is $view = new View('my_view', array('foo' => 'bar')); or $view->foo = 'bar'; or $view->set('foo', 'bar'); Obviously they will never be done the same way from controller to controller.

Symfony

Having a look at Symfony they seem to have a method to switch the view class, which I guess is almost as good a just setting a property. Unless you are one of the people that are worried about nano seconds that is, method calls are expensive.

Trawling through the docs there is a shed load of configuration files, one of which controls the view class and how it works. Symfony claims this is set to be the default best loved conventions, but can easily be tweaked to what ever you like. Some one needs to point them to the wikipedia article on convention over configuration. Direct quote 'Most of the time, you don't need to change the configuration, since the default conventions match the most common requirements.'

CakePHP

So what happened there? CakePHP expects files in a certain place and to have a certain name. So when you set $this->view = 'MyView'; in the controller it looks for app/views/my_view.php, includes the file, loads up the class and gets it ready just when the view is rendered. For plug-ins its much the same, $this->view = 'MyPlugin.MyView'; loads app/plugins/my_plugin/views/my_view.php

For CakePHP, there are no other methods to call, nothing to import or initialize. No views to explicitly render. I just happens. You do have the option of making CakePHP not render anything automatically by setting $this->autoRender = false; in the controller, and then you can happily duplicate your work in every single action of your application. You can also render random files or any other custom hacks you like.

Based on this, CakePHP really does take the boring repetitive coding out of your hands so that you can get your job done. There is no point having to call View::render() in every action of your application. Why do you want your classes to have names that you will never ever remember. Don't risk breaking MVC rules using views directly in the controller.

Taking it home

Yes, you probably could build a base controller in your other applications that sets up all of this and makes it more automatic, but the point is that CakePHP does it. The code is fully tested with the included test suite and every application you encounter works the same. Not some hack job that was copied from a tutorial site 4 years ago, written by a first time Php user.

CakePHP wins this one hands down for me. Next closest contender was Kohana with its semi-automatic, conventions based views. Zend comes 3rd with its easy to remember class names and Symfony does not feature because I could not be bothered to figure out all the configuration files.

So if you are writing the app for the first time from a clean slate, or taking over another application, you can be almost sure that for the most part every CakePHP powered application will work in the same manner. I don’t think you can say the same thing for the others that were mentioned. So, if your framework of choice does something better than another framework, stick it in the comments and ill dig around the docs and try find a winner.