jp's domain

Browsing around the wonderful programming.reddit.com last night, I came across a post titled Why Django kicks Ruby on Rails' collective ass. This is an interesting article, mainly because in a sense it is right, but it goes about explaining Django's benefits all wrong. First of all, Ruby on Rails ain't plural, and therefore it cannot have a 'collective ass'. Ok, I kid. But seriously, I started out my web programming 'career' with Rails, and I have since moved over to using Django. I'll try to list some constructive reasons why the 'pragmatic' (buzzword!) developer would chose Django over Rails.

Python

Python is the reason Django is as good as it is. Django follows Python's core concept of keeping things as simple as possible and understandable. This leads to much more maintainable code in the future.

And yes, libraries play a huge part in choosing Django over Rails. Python has a library for just about everything, and is used in so many programming domains. One such instance that led me to using Python over Ruby was my need of a DBF reader. You can't find this anywhere for Ruby, but I found a very solid implementation in Python that I was able to plug right in.

The other article made somewhat of a controversial statement:

Furthermore, since Python has a more active userbase and more frameworks, if Adrian Zolovaty, Jacob Kaplan-Moss and all of the Django developers suddenly dropped dead after I finish writing this, the porting of the code would be much easier than if Rails’ development stopped, where you would be stuck in the middle of nowhere if you ran into an issue.

Now obviously, if DHH did suddenly disappear, coding on Rails would not stop. But this quote isn't as far from the truth as you might think. Ben Bangert, the creator of the Pylons framework, has said that when he went about trying to port the routes URL dispatching system from Rails to Python, he found the source code virtually unreadable, and the implementation unnecessarily complex. Luckily, after talking to its creator, he was able to implement a faster and much simpler version in Python. It is worth noting that the Rails URL system has since been rewritten (I doubt because of this), though such complexity can be found throughout the Rails source.

The key reason why? Ruby programming tends to favor 'magic'. Basically coding practices which help you put together some quick, clever code. This is nice, but much like Perl code it can end up making code a PITA to maintain. In this manner Python's focus on being simple and explicit wins out.

One more thing: packages. Python's package system makes organizing your code so much easier. I cannot express how much better this is than than anything Ruby has. Ruby's module system doesn't even come close.

If you are interested in a more in-depth reasons why one might chose Python over Ruby, feel free to check out my article on that.

Documentation

Yes, documentation. In every single framework I have looked at, whether Rails, Nitro, Turbogears, Pylons, web.py, whatever, nothing matches Django's documentation. I do not exaggerate. The Django developers have done an outstanding job of documenting their framework and it is easy to understand for both the experienced and unexperienced Python/Django user.

Compare the online documentation of Rails to the online documentation of Django. It just isn't even close. It is for this reason that nearly every new Rails developer is told to pickup a copy of Agile Web Development for Rails. While this is a very good book, it will run you more than $20 and it simply can't beat the The Django Book, which is currently being developed with the help of the community, and will be available online for free, and in print at a reasonable price at some point.

It is things like this which led Guido Van Rossum to say that the Django developers 'get open source'.

Suggestion for Django: The documentation is excellent, but it doesn't cover everything. For example, it didn't say anything about there being generic views available both for login and logout. I found that out through digging through the source (which says a lot about how understandable the core code of Django is.

Templating

Now I'll be perfectly honest, coming from Rails, I initially really disliked the Django templating system. It felt like a strafe jacket. It was limited in what it could do, which is completely different than the eRB templating system for Rails which basically lets you put any valid Ruby code into the template itself.

However, having used the Django templating system, there is absolutely no way I'd go back to using something like eRB. As soon as I started using it, I realized that certain pieces of my code wouldn't work. I couldn't jam application code into the template. It truly restricted me to only formatting my content, which is exactly what a templating engine should do. And the Django developers are committed to this, which means it won't just turn into a PHP. This is good.

I quickly found that if I couldn't express something with the template system, I was doing something wrong, and it led me to think a little more about the structure of my app. This is a good thing.

And if you really do need something more than what the default templating system provides, both filters and tags are very flexible and powerful. This for example is one of my favorite examples of chaining filters together:

object.quantity|default_if_none:" "|intcomma

And this is my own custom filter that I wrote:

@register.filter
def ifin(value, arg):
    if value in arg:
        return "<b>%s</b>" % value
    else:
        return value

And how it is used:

field|ifin:record.1

Can you guess what it does?

It is a simple filter which allows me to bold an item if it is inside a list. This simple bit of code helped me to simplify my code by quite a bit and take all of the application level code out of my templates.

Oh, and the inheritance system absolutely rocks. You'd have to use it to understand what I mean, but needless to say I'm a huge fan.

Speed

Now don't let this point be a huge deal, because it isn't. Neither Ruby nor Python are relatively fast compared to say, C, and you can't use them to do everything. However, the entire reason I use Python is because I'd like to avoid C as much as possible. The common statement in the Ruby community of 'you can always drop down into C' scares me. What is nice about Python is it is just fast enough to where you can for the most part entirely avoid using C. With Ruby if you are processing large files or a lot of text (which I have in a few apps), things can really start to drag on. What is also nice about Python is if you really need a speed up, psyco does a very nice job.

This also carries over into frameworks. Most Rails apps that I use online have a slight bit of lag to them. Django on the other hand powers parts of of the Washington Post online. And as the other article pointed out, benchmarks clearly show that Django just blows away the competition.

The Django devs have said on several occasions that they have an eye on performance, and Jacob Kaplan-Moss has said that the templating language is so fast that caching it actually slows it down. Hopefully that will just give you an idea of Django's performance.

Admin interface

As Borat might say, 'Very nice'.

One thing that you must understand about the admin interface, and most people don't, is that it is not a part of the framework. It is not scaffolding. It is simply an application built with the framework that comes bundled with it. You can chose to use it or not. If you do use it, you can literally have the entire back end for your site up in minutes. This thing is flexible and powerful. It won't do everything for you, but if all you need is a back door which allows administrators to do basic work on data, it works like a charm. However, again, it won't do everything, and it was never meant to, which leads us to our next part...

Generic views

Generic views, much like the admin interface, are very misunderstood. They are not to be compared to Rails' scaffolding either. They do not generate any HTML for you. They do, however, do the grunt work of basic CRUD operations and such, and they are very flexible. Infact, the admin application is built ON TOP of generic views. This is a real piece of code in one of my applications:

from django.views.generic.create_update import create_object

@login_required
def create_vendor(request):
    return create_object(request,
        model = Vendor,
        post_save_redirect = '/vendor/list/'
    )

That bit of code right there will do validation on a 'vendor' object of mine, and create it. It'll even do me the favor of passing me error messages which I can use in my template however I'd like.

I cannot express how powerful these are. Because they are simply functions, you can wrap them in another function and through that manipulate how they are used. You could do most everything in most sites in generic views, and the equivalent manual piece of code to what I just showed you is about 3x as big. James Bennett does an excellent job of describing the simplicity, power, and flexibility of generic views here.

One more thing to keep in mind: much like the admin interface, generic views have a limit. Don't try and fit a square peg into a round hole. Most of what you want to do can be done with generic views, but sometimes they can't. It is at that point that you can drop down to the actual framework itself. Don't be afraid to do it, as a matter of fact generic views are built using the framework, and it isn't difficult to use. In this respect, Django is composed of layers. At the very bottom you have the core framework, which is the most low-level but also the most flexible. The next step up is generic views which are built using the framework, and are higher level yet less flexible. And finally at the very top, you've got the admin interface which is built using generic views and while still flexible, is a lot more limited than the other two. Again, don't try and force one part to be what it isn't. Use the right tool for the job.

Suggestion for Django: Generic views are very flexible, but their use cases could be expanded from perhaps 80% to 90% by a few very simple things. Like for the create-object generic view, how about an argument called post-save-callback (should be underscores, formatting won't allow it), which allows me to pass in a function which is triggered when the object is created? Little things like this, while easy to implement and light weight, would add a lot more power to generic views.

As you can see, generic views themselves also can't do everything, which leads me to my next point...

Simplicity and flexibility

Everything about Django is simple. To create a page, you write regular expression in your urls.py file which maps to a view function. The view function only requires a request object as an argument (HTTP request), and once it is done processing it either generates a response (render an HTML page perhaps), or redirects or whatever else. It is that simple. There is nothing complex about Django, and this is one of my favorite parts about it. It is this simplicity which allows me to focus on my application and not the framework.

You might think that simple means limited, right? Wrong. This simplicity leads to great power and flexibility, as seen in the case of wrapping the generic view above. It also allows neat things like middleware. This is one of my favorite parts of Django, let me give you another example.

Django when given POST data, will setup request.POST, and if a file is uploaded, request.FILES. This is nice, but I quickly found out that due to Django's thorough parsing of uploaded files, was too slow for me. So what did I do? I wrote a middleware which setup request.POST and request.FILES how I wanted them. Basically, middleware is like a hook into your application which allows you to do something before each request, after each response, etc. It took 20 lines of code and now Django works as I want. It is like I went in and edited the core of the framework, but thankfully I didn't have to, and now whenever my app needs to upload files, I just drop in my custom file middleware, enable it in settings.py, and that's it.

The little things

Oh, the little things. How about Unicode support? They are working with it in the Rails community, but there still isn't a final nor perfect solution. Django on the other hand, just works, because Python has native Unicode support. You can't beat that.

How about ORMs? What if you don't like Django's ORM? Let's say you really really dig SQLAlchemy? No problem. There is nothing in Django which ties you to an ORM or anything else for that matter. Plug it right in. And if that weren't enough, there is a project which implements Django's ORM on top of SQLAlchemy, so you may soon have the simplicity of Django's ORM along with the power of SQLAlchemy. Try using Rails with a different ORM than ActiveRecord. Yeah...you might as well write your own framework at that point.

What about server support? Django supports Python's standard, called WSGI. This basically means that Django can run on any server that supports the rather simple WSGI standard. This includes FCGI, SCGI, CGI (if you are crazy enough), mod_python, and any number of Python servers. Infact, my own apps are running as Windows services off of the Python servers found in the Paste libraries. These last two items are direct advantages of Django using Python as opposed to Ruby, which does not have as much support for such solid standards nor libraries.

Ah, one more thing which is a criticism of Rails and a praise of Django. One thing that is thrown around a lot in Rails screencasts and such is the 'easy validation' that you get. Well, yes, the validation is indeed easy to use, but it is very limited. What if your HTML form isn't tied to a database? What if it is simply a form which uploads a file along with some settings for the upload? In Rails you'd be out of luck, you'd have to manually do the validation yourself. In Django that isn't the cause, you'd simply use a custom manipulator to populate and deal with the validation of your forms.

Reality, not buzz-words

Rails deserves to be recognized for being the first framework to really get people to understand just how useful a web framework can be and the fact that they don't have to be massive titanic monsters like Zope or a Java alternative. However, I find that I'm not the only person in the Django community which at once time used Rails and has since moved over. Sometimes all of the hype and buzz about Rails can hide some of its deficits. And that's one of the nice things about Django, is it isn't about hyping things up as much as it is about getting things done. Heck, the framework hasn't even yet hit 1.0 (yet it is still stable), and the Django devs have said that it is at that time which they will finally begin to 'market' the framework. Sure, Django doesn't have AJAX built-in, which would be nice to see, but that is something that is being looked at and it isn't hard to plug in whatever AJAX framework you want to use yourself. In that respect, you don't have scriptaculous (which has a number of criticisms of its own) shoved down your throat.

You also don't have things like PostgreSQL more or less ignored (or shall I say the database treated as retarded) because Rails is 'opinionated'. Finally, you don't have DHH. As much as I like what the guy has done for marketing Rails, he just doesn't shut up. He's constantly creating controversy and getting in a flame war with somebody, and long term that will not help Rails get adopted into serious work environments. At this point DHH is as dangerous to the future success of the Rails as he his helpful. It is a bit like a gas depot sitting right next a firing range. In the Django world, they try and keep those separate, thankfully.

These are my humble observations on using Django instead of Rails. If you are a serious developer wanting to chose the right framework for your business, or startup, you owe it to yourself to seriously consider both frameworks. And I do think that Django is a very good choice that is difficult to beat at this point in time, and will only get better as it reaches a 1.0 release, gets a finished book, and continues to attract new developers.

last updated 1 year ago #