Rails - Django Comparison

On the one hand, you really miss the talk that these slides were attached to. Browsing the slides by themselves is kind of tedious and lame.

But the split-screen format really drives home the message that Rails and Django -- apart from a few minor differences that will probably converge over time -- are the same thing, implemented in different languages. There's just not a lot in there to hang a flame war on. Emacs vs vi, this isn't.

Slide 68 indicates latest Rails version is 1.1.6. The document was uploaded on 19 June (I'm guessing 2007). Is this really relevant now?

I will tack on that the framework will not make or break your idea. The advantage of one framework over another should be weighed in how long it takes your team to go to market; this translates into asking your development team (or yourself) what they (or you) can handle in the coming months in anticipation of the project taking off. Also your code should be done in such a way that you can ditch whatever framework you currently use for something better suited for what your future requirements might be.

I will add that I believe TurboGears to be the better platform all around, but am sticking to Rails because:

1) I like Ruby/Rails

2) I don't have the time/energy to dive into Python/TurboGears

3) I can implement something by myself confidently in Rails RIGHT NOW, as opposed to a few months down the road after getting comfy with Python (while at the same time maintaining my day job and OTHER life responsibilities)

I went with Django because I could read its codebase, but found the Rails codebase too cryptic. Rails magic, epitomized by the pluralization rules, was also a turnoff - the prospect of debugging in that world seemed scary.

The case for Django is the clean, modular architecture, making it possible to split a project into reusable applications. With Rails DHH took a strong anti-component stance, deciding that it was better to make everything easy to reimplement. As a result, even common things like the registration gem have too many integration points. This decision will matter in the long run.

Django has access to all the mature Python libraries, but its ORM is limited. Pythonic model specification and automatic model validation against the SQL metadata is great for the DRY philosophy; but there is no migration metaphor (yet), there's no table inheritance metaphor (yet), and even pessimistic locking requires a hack (so far). The best hope is an effort under way to make the Django ORM a wrapper for the infinitely more powerful SqlAlchemy, which some people use on top of Django anyway, foregoing its data-related tools including Admin.

And of course Rails is integrated with every concievable Ajax technology, allowing a hundred ways to implement the <blink> tag.

The Rails community is growing from an influx of ex-PHP scripters, bringing with them less disciplined coding styles, which the more Perl-like overly-concise features of Ruby encourage. The RoR environment is going to be the new Perl - a powerful tool for certain applications, applied far more broadly than intended, with a CPAN full of one-off solutions for every concievable problem, but no culture of solidly engineered modules.

I wrote my app in Python/Django. My reasons were short:

1. I wanted to learn python, but was not really interested in ruby 2. Rails is too hyped. The problem here is that people pigeonhole you when they hear that you are a rails developer. If someone ever came to me and told me he was a rails developer, I would immediately perceive this guy as someone who jumps on technology bandwagons. The type of guy who listens to top40 charts. 3. Django just had a way better argument when it came to performance

and the most important reason of all

4. When I created a new Django project, it just created 3 files. Rails (when I tried it) created a bunch of folders and files. People have to understand simplicity in all its facets to be effective programmers, in my opinion!

My question would be why did rails' models take so long to do compared to django. The examples they gave the rails were shorter (granted neither were complex) I'm going to assume that they have the same number of models (5ish) so it can't be that.

I especially liked the fact that they did not seem to have any bias going in or coming out. And, they actually built the same site using both frameworks and took notes along the way - all in all, very commendable.

They're comparable enough that the individual programmer matters much more.

I say pick one, learn it as well as you can, don't worry that you picked "the wrong framework", and go with it.

Slightly unfair comparison when it comes to admin pages. When it comes time to modify the Django admin pages to do something the framework doesn't supply, I bet the graph gets a bit more even, if not in the favor of Rails.

This is true of any framework: the second that you go outside the bounds of what it was designed to do, you are going to spend lots of time bending it to your will.

When Rails and Django compete... we win!

What's the original format of this presentation? Why can't I just save it as a PDF or view as HTML?

Good to see some actual experiments with the different frameworks, not just expert thoughts.