Django vs Rails | Hacker News Reader

Django vs Rails

beta.feedmagnet.com

16 pointszeynel127 comments

The answer to this question hasn't changed. Choose one or the other based on:

  Language knowledge (Python v. Ruby)
  Availability of developers
  Amount of third party code specific to your needs

This topic has been thoroughly gone over a number of times, this article doesn't really bring anything new to the table.

The "magic" versus "timesaving" differences of philosophy is a new way of putting it. It encapsulates a gut feeling I had about the two but hadn't put my finger on until now.

Especially when starting from scratch, learning RoR is kind of like "ooh, shiny, magic, wow!" and learning Django is like "so you do this, which does (this and this and this behind the scenes), then do this..". I love magic as much as the next gal, but not being able to fully grok RoR from the start was partly why I chose Django as well.

It's open source. Start groking.

This basically just says Rails has a better user interface than Django (not necessarily something I agree with).

Django makes you feel like a power user because it forces you to learn more in order to use it?

There's a limit to how much I want to try to read up behind a tutorial when I'm just trying a new framework out. If my natural desire to understand what magic lines of code does causes me to break focus, tab out, google a bit, find some explanation that may or may not even be correct... yeah, I get put off a little.

And yet the argument here in favour of Django is that not as much is hidden from the user... which may cause some users to lose focus as you put it.

I find this this statement hypocritical.

I'm not sure where you managed to conflate my use of the word "I" with generalisations about "some users".

To me, this difference is encoded in the development philosophy of Python vs. Ruby.

If you like the meta-magic of Ruby, you'll probably like Rails. If you like the straightforward nature of Python, you'll probably like Django more.

There are many more Rails developers out there, but there are also a lot of hacks in the community. There are probably close to as many good Django developers as there are good Rails developers - you just don't have to hunt through the bad ones as much to find them.

Sorry, what? How could one possibly know there are more hacks in the Rails community than in the Django community?

I'm all for comparing the merits of various languages and frameworks, but this article is more about gut feelings than facts.

I agree entirely. My impression was that he feels rails is too accessible and hence there are too many hacks using it.

He wanted to feel more like a hacker, and rails hid (of course by hide he means publishing the source code) too much of it's magic.

In fact, I think publishing an article on Rails v.s. Django and posting it to Hacker News stinks of SEO.

Hi there - this is Jason - the guy who wrote the original post. I just found this forum with comments via a Google search. Actually, the only place I posted a link was on a moderated Django Google group. The linking and commentary came as a surprise to me - I wasn't really sure anyone would read it! Not sure who posted it to Hacker News.

My bad Jason. Your article struck a sour note with me that day for some reason.

Before you go any further, you should know these things:

1. Deployment and scaling is a lot easier on Rails b/c of several dedicated hosting providers that specialize in Rails. Engine Yard is the one we use, it makes scaling extremely easy. I'm not sure if Django has similar companies.

2. Rails-specific SAAS are super awesome. Newrelic/Hoptoad, etc. They make tracking your software and errors a lot easier than the less supported Django.

3. Speed is a non-issue; scaling is 100% about making the DB scale. Furthermore Ruby 1.9 is going to be faster than Python 2.

4. Training a developer to learn Django is not as trivial as you think. There are a lot of "tricks" in these frameworks that make working in them very fast, these take time and experience to pick up.

For #1 - There is Google App Engine.

"It approaches the problem of building a web framework in a unique way and doesn't even attempt to share terminology with Rails for things as basic as model-view-controller (Django uses the terms model-template-view instead). "

I can't really agree with this being a good thing. The MVC pattern has been around much longer than Django or Rails, thus Rails is using an existing nomenclature where Django is not.

Django doesn't call itself MVC because it isn't MVC.

Could you elaborate on that? I've used both and the difference (apart from the naming) is too subtle for me (not trolling - honest question).

It's a subtle but important difference.

Rather than MVC (Models, View, Controller), Django uses MTV - Models, Templates and Views.

The M in both is pretty similar, and is typically an object representation of what is in the database.

Django differs from the more established MVC model. In Django-speak a view is a function that takes optional arguments, processes data on the model, and (typically) outsets key/value pairs of object. They key/value pairs get fed into the template. E.g. if you did had a URL /sales/by_country, then a view would be executed that would do a query that returned the sales by country in a pure python data-type (e.g. a list). All the presentation code, would be be done in a template.

In MVC, you have controllers that were the 'business logic' and views that were the 'presentation code'.

MVC is arguably more pure from a design perspective, MTV arguably fits more naturally with the way the web works.

This 'snakes and rubies' video starring DHH and the Django team is a good session that explores it in more detail. (http://video.google.com/videoplay?docid=2939556954580527226#)

http://docs.djangoproject.com/en/dev/faq/general/#django-app...

That's a specious distinction, even if I can understand their interpretation. It's just easier to say that:

1. Django Templates correspond to Rails Views (they both define how data is presented to the client). The biggest difference is that it's easier to include business logic in Rails Views because the Erb template language is as expressive as Ruby itself, while the Django template language is deliberately restrictive.

2. Django Views correspond to Rails Controllers (they both process requests). The biggest difference is that data is passed explicitely from a Django View to its Template, while data is passed implicitely from a Rails Controller to its View.

What's also important, but not addressed in this article is the kind of app you are building. I'm generalizing a bit here, but Django seems to focus more on the CMS-y content type of applications whereas Rails shines more for non-traditional kinds of web apps.

I think it's important to note where these frameworks come from. Rails started as a means to build a web app. Django started as a CMS for online newspapers.

I toyed with Django for a while before I moved to Rails. The main force driving me to Django first was that I already knew Python, whereas I'd never really used Ruby. I chose Rails over Django because of the magic. It seemed like I had to learn a lot more up front to get a web app working in Django, where I could get things working first in Rails while learning what the framework is doing over time.

The article has a very reasonable tone, but a headline like this is unlikely going to spawn anything but the relaying of subjective experiences on why or why not the authors points are or are not total bullshit.

The references section could benefit from including why's classic Ruby vs. Python video:

http://www.youtube.com/watch?v=mXZ_htL1rOI

I don't really know into deep the Rails community but what you say regarding Django's it is true. I really like the average mindset of the folks in that community.

The article seems to be just generalizations and hearsay.

Yeah - I'll go ahead and address this here since a couple people said something similar above. I suppose I could have prefaced the post with a note on the "gut feel" nature of my arguments. I spent a month or so evaluating the platforms, interviewing developers who were proponents of one or the other, talking to friends and colleagues who had strong opinions, reading lots of other blogs, and diving into tutorials and documentation for both frameworks. In the end, I formed my own opinions shaped by the people I talked to, the things I read, and my own experiences. In the post, I'm not even attempting to provide concrete data - and most of my points are about things that you'd have a hard time measuring anyway, like philosophy and culture.

I'm not trying to stand on a soap box one way or the other here. Maybe a less combative post title could have helped tone down the commentary. The reason I wrote the post was that I had found myself explaining my decision to a handful of people and I thought maybe more folks could benefit from the "research" (intentionally in quotes to designate that is was not "real" research) that I did while getting ready to make the decision.

If you want to fire arrows back and forth at each other, feel free. I'll probably not get too involved though since I don't always find those discussions productive.

- Jason (author of the original post)

can we kill this thread before it devolves?

Reply on news.ycombinator.com