Rails vs Django
After getting more into the depths of Django I was all set to write a comparison article, then I found one made by two guys who made the same website with both frameworks. Nicely written, lots of detail, objectively puts forward the strengths and weaknesses of both. Unfortunately the documents are not presented on a nicely written website, but in a subversion repository. I’ll put the links to the external resource first, but if those go away feel free to use the mirrored copy of the article below.
Rails vs. Django:- Docs directory
- Rails vs. Django article [pdf, 132 KB]
- Rails vs. Django presentation [pdf, 6.7 MB]
While both frameworks do a great job of producing databases from their corresponding language code, my biggest complaint with Django is that it lacks a counterpart to Rails’ migrations. Migrations enable a Rails projec to incrementally develop the database model. Essentially it’s subversion for the database structure. You build up changes (adding/removing/altering tables, columns, etc.) using ‘migrations’ and can apply them or roll back at your whim. Django, on the other hand, really wants a fully formed database structure to start off the project. Any changes after the initial creation have to be shoehorned in by: 1) adding the stuctures to the database directly, then 2) updating the database model within Django…bleh!
Django is clearly designed to get sites with simple models up and running fast. Using it you can definitely feel its lineage as a rapid news story development framework. Rails feels more methodical, a framework for building many types of applications but with a corresponding increase in development time. But that’s just me. I’m much more familiar with the Ruby language and (as the Rails vs. Django article concludes) both frameworks are essentially equally capable, so go with the one that uses the language you know. There is a lot of awesome (and not so awesome) in Django and Rails.