I have a nice little pet project to work on … but I’m facing a bit of a dilemma right now. The project is a web-based tool to analyse information, and my debate is … which of the these 2x awesome tools should I use?
Django (which runs on the Python language) is what I’m currently experimenting with. And the one I’m thinking of using is CakePHP (which runs on the PHP language). Both Python and PHP are what I’d consider, “Scripting” high-level languages. Python is a great “glue” language. I feel Python has more promise than Perl for multi-developer situations, in that Python encourages good programming style, while Perl gives you enough rope to do the job, with left over to hang yourself, your tester, maintainer, and documenter with. PHP suffers a bit of the “spaghetti” criticism too.
I’m keen to use a tool that simplifies web development as much as possible, so I can concentrate on my pet project, and worry less about the low value-add stuff. I first thought of using Ruby on Rails (RoR) but I was rather turned-off by the feelings of the community towards its performance and governance structures.
So I’ve settled on something “similar” to RoR … I picked two frameworks that were in part inspired by RoR: Django and CakePHP.
One thing about Django is that the database layer doesn’t make you get down & dirty with SQL and similar tools. You’re always coding in Python. For example, when doing the “Model” part of the MVC paradigm, let me show you this example from the Django Book:
from django.db import models
class Publisher(models.Model):
name = models.CharField(maxlength=30)
address = models.CharField(maxlength=50)
city = models.CharField(maxlength=60)
state_province = models.CharField(maxlength=30)
country = models.CharField(maxlength=50)
website = models.URLField()
class Author(models.Model):
salutation = models.CharField(maxlength=10)
first_name = models.CharField(maxlength=30)
last_name = models.CharField(maxlength=40)
email = models.EmailField()
headshot = models.ImageField(upload_to='/tmp')
class Book(models.Model):
title = models.CharField(maxlength=100)
authors = models.ManyToManyField(Author)
publisher = models.ForeignKey(Publisher)
publication_date = models.DateField()
So far, my experience with Cake PHP is that the first step with developing an app with the framework is always to design the database first and make sure it’s properly normalised. This isn’t too bad to do in phpmyadmin, everyone’s favourite MySQL admin front-end.
So let’s see:
- Ruby on Rails (Ruby)
- Trade-off of computing performance vs. time-to-develop. (RoR is slow, but at least you develop fast). Although, this may be less of a good trade-off, given similar frameworks with better computing performance and similar time-todevelop.
- Has mod_passenger, an Apache module that can accelerate performance of RoR apps. This might alleviate some of the performance issues above.
- Not selected for further work – see Wired for more info.
- Django (Python)
- Not as straight forward to deploy as PHP. Requires some convoluted deployment strategies, and can be a headache in shared-hosting environments (i.e. places you don’t get root)
- Python is the new hawtness, and Django is also embedded as part of the Google App Engine.
- Poor resources available in Brunei, awesome online and built-in resources.
- CakePHP (PHP)
- Very easy to deploy on any web platform on any OS … Apache on Linux, IIS on Windows, etc etc.
- Plenty of resources available – coders w/ PHP skills, training courses, certification, books, magazines, etc.
- The framework is strict on code structure, which is an advantage in dispersed development teams.
At the end of the day … Django is a bit of a gamble right now (as is RoR for that matter!) for me to use for my pet project. If I want to get help in the future – people will be more interested if it’s a platform they are familiar with, and PHP is well-known by many, so there’s a bigger pool of interested people to draw from.
No related posts.
Pingback: Rapid development frameworks - CakePHP, Django, RoR - Relevance Found
I am in a similar dilemma … I went through the poll application tutorial for Django and the blog application tutorial for cakephp … I felt Django to be much faster in terms of development and customization as compared to cakephp (eg user authentication, validation modules etc are configurable in Django as compared with cakephp, which needs some amount of customization on top of it) … at the same time growing popularity and the amount of online support to cakephp left me a bit confused. It will be good to know which option you finally went for and why … thanks
Hi Kapil,
Actually, I went with Ruby on Rails in the end because I eventually lost my initial reservations about RoR.
So, after giving RoR a try, I closed off exploring the other options.
Here’s my take on it:
http://opensourcemissions.wordpress.com/2010/06/21/cakephp-vs-django/
Has your opinion changed since you posted this? Django has come a long way since then, as I imagine CakePHP has, too.
Not way… Django is big daddy
I use CakePHP. I tried Django, it seems awesome but I preferred the easy to install everywhere CakePHP.
Pingback: Tweets that mention CakePHP vs Django dilemma | Relevance Found -- Topsy.com
I have used a lot in the past CakePHP but I didn’t like the framework so much when I tried Ruby on Rails I just never looked back, sometimes I work with PHP using CodeIgniter but I prefer Ruby. Rails might be slow but belive me when it’s deployed it’s a lot faster. One thing that ROR beats CakePHP and Django is the comunity, you will find a lot more documentation, tutorials and videos, that it’s really important to learn something new.
Django is the easiest of them all to learn “by a long way” as long as you already know the languages of each. Very easy to learn and great free books. Sadly not any good vids like Rails has but the Django book is VERY GOOD! Believe me it is well done. Every bit as good as the Rails stuff on Lynda.com.
I bet any coder can learn the entire Django framework in a month enough to start using it with reference materials handy! I don’t think you can do that with Rails myself.
I like Ruby and Rails but I find it slower to work with that is the problem. Yes it is elegant but it is slower. Ruby is an addictive language not for easy syntax like Python but because you feel special you understood it’s quirks and can tell everyone about them. Ruby is much more like Perl than Python will ever be. They are a like in many ways Python & Ruby. Both great lanuages for the web and both updating so don’t jump out of one before you check roadmaps etc.
PHP has far to much went down the road of being for non trained programmers. Many users never did computer science as a degree. So it has always catered for this. Python and Ruby are more appreciated by us that did the computer science degrees over the fell into web dev people who favour PHP I think. PHP is good cake is good they can do most of what the others can but would I use it over Rails and Django NO WAY!
Django Template system is faster than any of the others it is much freer. Rails likes to think CSS and JS are part of it which is silly because when I work I have a CSS/JS/JQuery guy who does my templates then I code into them. The last thing I bloody want is those art types in my code! So thank you django for getting these roles split. Imagine a plumber trying put his pipes next to your electrics!
I have also looked at CF on Wheels it is like Rails and Django but for Cold Fusion. Cold what I hear you say lol. CF is just not good now…very slow also and cumbersome to install on Linux and you can’t even get on BSD easy AFAIK. What idiot uses a Win box as a web server in 2011! The language is a joke of tags very unsuitable to frame working. They have this CF script rubbish. I think they are moving to it but who cares it is too expensive and not enough users and free stuff. It is poor stay away.
Oh Java is awesome not talked about it – if your in enterprise level but most of us are not so no need to discuss it here.
So your choice is Django & Rails if you are in small-medium work and need things done very fast and changed very often.