a short view on Django compared to CakePHPphp

31 08 2008

I’m trying to get the difference between Pythons Django and CakePHP but iam more than depressed how many people (especially from the Django base) don’t like PHP at all (or make fun of it). I thought that there might be a good reason for it and compared the Frameworks against each other and mainly found out that most difference’s are just „small stuff“.

To compare this both Frameworks is quite easy. Both started nearly at the same time and try to reduce the „dont repeat yourself“ factor. Django and Cake both use a MVC (Model View Controller) like structure to reach this goal.
Both support Database Abstraction (Mainly both support the really important Databases -> Postgres and MySQL).

The Strength of Django is the smart Query generation. This is defiantly something CakePHP needs to work on. Testenviorments / Ajax / buildincompontents are the strength of CakePHP. Django should get rid of real html tags and replace them with functions. The Code looks cleaner in PHP to me (cause i like to have all information at one place), but i think bad formation of the code can annoy a lot of people which have to program with someones else code. The use of forming ARRAY’s is essential if you want to use clean CakePHP code.
Lets Talk about something damn important for Programmers -> Documentation. The good point on Django, is they have already a book out (even if they dont have a final release yet, but there will be a stable version soon. Only some days to go). Cakes documentation is really good, they just rewrote it and some parts are still missing. But you will find everything quite fast if you just get the main structure of the documentation. Djangos documentation is a bit under this but still really good to use. Cake has got a strong focus on the community behind it. With „the bakery“ and „CakeForge“ they give the users a easy access to all source people just produce. Thats something Django needs to work on.

Project Language Ajax MVC framework Push/Pull i18n & l10n? ORM Testing framework(s) DB migration framework(s) Security Framework(s) Template Framework(s) Caching Framework(s) Form Validation Framework(s)
CakePHP PHP Yes, Prototype, script.aculo.us Yes, Active record pattern Push Yes, Development branch Yes, Active record pattern Yes, Unit Tests Yes Yes, ACL-based Yes Yes, Development branch Yes
Django Python Yes Yes Push Yes Yes, Django ORM, SQLAlchemy Yes No (plugin exists, might be merged into trunk when more stable and feature complete) Yes, ACL-based Yes Yes Yes

One Reason why the Cake looks a bit cleaner to me is for sure the View Design. Its a bit more straight forward. Django does this on a more old fashion view. This makes it easier to new persons, but if you really want to separate the view to „designers“ it is cleaner to use Cake.

django view Cake view

{% if form.errors %}
Your username and password didn't match. Please try again.
{% endif %}
{{ form.username.label_tag }}: {{ form.username }}
{{ form.password.label_tag }}:{{ form.password }}

echo $form->create('User', array('action' => 'login'));
echo $form->input('username');
echo $form->input('password');
echo $form->end('Login');

Most important stuff can be found in CakePHP directly. Some important things need to be loaded for Django (like mptt) but therefor django got a „instant server function“ which can be loaded for CakePHP in additional (cakephp-instaweb). So both Frameworks have got software which need to be loaded if you want to use it for the most common needs.

Final Words:
CakePHP and Django are both good Frameworks. I think its mainly a question of what your settings for the final Product are. If you need to work with a normal provider (no vhost or something) django is out of that business. mod_python is only rarely spread yet, and to start a real server process is most of the time not possible.
If you don’t want to change a lot djangos generic views and Cakes scaffoldering both are great, but i don’t like totally preconfigured templates at all so i dont really care about them.

If you need the performance and got enough time and admin rights Django is the correct choice.
If you need to code faster, and dont want to do everthing on your own, CakePHP is the right choice.

Overall, there is only one bad choice -> to ignore a good framework at all. As long as you use a good framework you will produce code with a much better structure while you save hours. The Stepback to a non Framework based development is the only wrong decision. And after all, both are just copies of „Ruby on Rails“.


after testing a bit more with django and postgres i found some „leaks“ in definition. If you use PostGresql with Django the default table defintions (auth etc) wount generate correct OIDS for PostGres. In fact postgres dont need them, but only if you are sure that there are never 2 entries with the same value. For MySQL users this is no problem, cause with mysql you can delete the entry by using LIMIT 1 for the DELETE command. Postgres needs a sessified OID to do so. So if someone explicit does crappy things with the database -> the default Django design would be wrong and have to be altered.

And just cause many think its a feature that they have to use instat of apache webserver -> Django explicity tells you to not use the internal webserver for a productiv enviroment. Thats what they tell use about it:

Now’s a good time to note: DON’T use this server in anything resembling a production environment. It’s intended only for use while developing. (We’re in the business of making Web frameworks, not Web servers.)

And some Statistics from google where red is CakePHP (keyword : „cakephp“) and Blue is Django (keyword: „Django python“ otherwise the musicartist will be counted eiter)

just to come clear about this image: it should not display A is better than B, but it should give a view on popularity (one big fact is that PHP is more public than python, which is not the best descission). But the Graph can be a indicator for available addons / support by irc and all other community related issues.

Django is more or less deprecated. The projected has bean moved into other projects…