Django – next stop after Ruby on Rails?

Having done web development on several platforms (Perl+CGI, ASP.NET and PHP), I was introduced to Ruby on Rails about two years ago, and it was love on first sight. The separation of code and layout was a bliss after PHP require statements (and vaguely similar to ASP.NET, by the way), and database abstraction was on a wholly different level.

And, you don’t need semicolons after statements in ruby, just how sexy is that? What more can a man need (write a comment, if you disagree :).

Now Rails does have some annoyances, like painful configuration for multiple applications running on a same server. If someone actually likes writing Lighttpd rules and making special provisions for it in routes.rb, again, let me know. It also seems that in some cases, all the abstraction and “there is a really clever hack to do this with just one line of code” -mentality has taken over good sense, which for me has meant that my “Rails 0.9” skillset has been mostly deprecated, and replaced with layers upon layers of new stuff I should be continuously keeping up with.

Now a recent Slashdot article (the one linking the page-long rant from Mongrel developer) had some positive comments related to Django, and I decided to check it out. And guess what? It just rules.

Now if you like your trusted PHP or like to roll on with Rails, wherever they take you, please don’t read further. But for those adventurous who don’t think using indentation to format blocks is a bad idea (Python developers obviously didn’t, and Django is a Python framework), I think there are several lovable features in Django, when compared to Rails. These are, of course, my personal opinions, speaking as a person who has developed a fairly complex Rails project (a personal budgeting app) over two years of time:

  • Creating a new Django project means only four new files, and application inside that project is three more. You read that right: seven files. Talk about knowing what does what, when an empty Rails app is over 3400 files. You read that right too. Of course Django has libraries and templates elsewhere, but I do like them being outside of my personal project.
  • Instead of scaffolding, Django has opted for admin generation, which I personally slightly prefer, as it often goes that any pages facing outside customers need heavy customization anyways.
  • Database structures are created from Django definitions. This is DRY at its best. This also means, that any necessary length constraints are already there when you start making your forms. Of course Django won’t overwrite your existing tables, which generally gives about the same leverage as Rails does with its database conventions, which you have to follow if you want Rails to play ball. With this feature, you can totally skip the “now lets write the SQL”-part of creating new applications.
  • Powerful templating system. In Rails you mark where you content should go in the page using layouts, but you don’t get any more levels than that. Django, instead, starts with a root template, which defines a set of blocks, which you can then overwrite (or not) by inheriting the template. And inheritance can go multiple levels, so you get same kind of benefits as you get when abstracting classes in object-oriented paradigms – you only override the parts you want to change, and recycle the rest.
  • Very good documentation. Just point your browser to Django overview and you’ll probably understand. It’s smartly written, and covers things you need, without the need of Googling too much.

And of course with Django, you get to write some kick-ass Python code, without any braces or endif annoyances, just beatiful, indented code. And I’d expect the Python libraries to be as extensive, or probably even more so than Ruby’s. I haven’t done testing to see whether Python’s habit of compiling stuff into byte-code speeds things up when compared to Ruby, but I don’t think Django would lose to Rails much when speed is compared.

Now that I got you convinced to check Django out, I do have some quibbles with it, which I think need to be resolved to make me abandon Rails completely:

  • No real API documentation. You have pretty good “how to use” documentation for everything, but I’d like to see the details if necessary, please.
  • Mod_python may leak memory and need restarting from time to time. This is not a nice things. Also, you need to have a separate server handling all non-Python data, as Django is quite slow at serving those images and other stuff you need for your web page.
  • Rigid templating language. I understand you shouldn’t put too much logic in your views, but not being able to use operators in templates is annoying. Example: there are only “if bool” and “ifequal var1 var2” statements, no “if size < 6", or anything like that. I also don't know how much performance hit occurs because of templating.

That’s it for today, time to do some actual coding. In my next post, I’m going to forget Rails and Django for a while, and discuss solutions for those cases where you cannot use the shining light of these solutions, and have to rely on plain old LAMP to survive.

Published by

Joonas Pihlajamaa

Coding since 1990 in Basic, C/C++, Perl, Java, PHP, Ruby and Python, to name a few. Also interested in math, movies, anime, and the occasional slashdot now and then. Oh, and I also have a real life, but lets not talk about it!

One thought on “Django – next stop after Ruby on Rails?”

Leave a Reply

Your email address will not be published. Required fields are marked *