

Ask HN: Updated recommendation on Rails versus Django? - phiram

Hi guys.<p>I realize this post is an infamous "versus" question, and undoubtedly redundant with older posts. However, most of the information I find on Rails versus Django is out of date and based on much older versions of the frameworks, so please forgive me.<p>First and foremost...I'm a Rails guy. I came to it three years ago and really enjoyed a lot of what it brought to the table. I'm not solely a Ruby guy...I have around 11 years of total experience, including Java, C/C++, Perl, Tcl, (some) Python, and more.<p>Anyway, I have an idea I believe will take over the world. I've already convinced a few folks it will as well and have friends and family funding to take on some offshore developers and get it in beta as quickly as possible.<p>Now, however, I am left with the decision of what tech to use. While I've really enjoyed Ruby...I'm growing tired of the magic, and the abuse of open classes. It's very nice when you need to inject some behavior quickly, but it can become a real pain when you have to maintain your project, or any of the plugins it depends on. I personally prefer Ruby over Python (largely because of blocks), but I envy the clarity-first attitude in the Python community. Given this frustration, I'm seriously considering a deep-dive into Django and using it for this project.<p>The pluses I see on the Rails side are:
1. Size of community (which, given some of this "community" includes PHP refugees, is not necessarily a plus)
2. My familiarity and experience
3. Number of companies using it and striving to improve it
4. Availability of offshore resources<p>Drawbacks of Rails include: 
1. Too much magic
2. Documentation continues to be awful in places
3. Inconsistent API
4. Did I mention magic?<p>The (perceived) pluses on the Django side:
1. Clarity
2. Performance...I believe Unladen Swallow will really change the Python landscape and give it a competitive advantage
3. Google's support of the language itself (see #2)<p>Drawbacks of Django:
1. Learning curve
2. Smaller community
3. Slower development cycle of the project itself?
4. (un)Availability of offshore resources<p>So, this is my thought process so far. I'm pretty comfortable I could come up to speed quickly on Django, and I have the basics of Python still in my memory somewhere. But I wanted to get your opinions as I really respect the vision and experience of a lot of the folks I read on here.<p>I appreciate your help. I really think this idea will take off, so it's very important to me to make the right technology decision.<p>And saying to choose Rails simply because I have experience there just doesn't sound right. If that were the case, I'd still be using Perl or C.<p>Thank you!
======
keyist
You're thinking of putting aside 3 years of experience in Rails and Ruby in
order to learn a new language + framework. On a project that you're taking
friends and family funding for.

While it's easy to pick up a language or framework, you only pick up best
practices by constant usage and community involvement. How are you going to
assess the Python and Django competency of your hires if you're that new to a
language? How will you make competent estimates for a technology unfamiliar to
you?

Both frameworks have been successfully used to rapidly prototype web apps.
When you say "make the right technology decision", that is _always_ defined by
context. And in your context you have 3 years of experience in one, and 0 in
the other. Unless the new technology is demonstrably far superior to the
incumbent one, you'll probably be better served by going with what you know.

Note that my answer would be the same if Rails and Django were reversed in
your post.

------
shabda
I am obviously biased, as I run a django development company. That said, Ill
start with answering the drawbacks of Django,

1\. Learning curve.

Not more than any other framework. Plus the Documentation is top notch. (The
documentation was what sold me when I was evaluating.)

2\. Smaller community

Definately true. But beyond a critical size, size of community does not
matter. Django is well above that size. (Irc: any given time ~200 Devs. Google
group: 14000+ Users )

3\. Slower development cycle of the project itself?

Why? If you give more details, I can answer that.

4\. (un)Availability of offshore resources

Definately less than Rails, but still not as bad as you would have thought. A
very small list, [http://uswaretech.com/blog/2009/03/web-development-
companies...](http://uswaretech.com/blog/2009/03/web-development-companies-
working-with-django/)

Thats said, given the information you have, I your case I would choose Rails.
Even if most of the work you are looking to offshore, your existing Rails
experience would be a huge plus, helping you evaluate vendors, keep track.

------
jm4
If you've borrowed money from family and friends to hire some developers in
order to get something working as quickly as possible you should use whatever
tools are going to help you make that happen. You probably don't want to be
tinkering around with a new language and framework on top of having to work
with developers you're unfamiliar with when you're dealing with a project of
this importance. Use what you know. If you have reservations about Ruby and
Rails start thinking about one of the other languages you've used to get
important work done. You can always explore other options once you're making
some money and have paid back your initial investors.

Personally, I'd be a little miffed if someone accepted my investment for a
specific project and then was using that project as a testbed for some fad web
framework for no good reason. These people have placed their trust and money
with you. You have a responsibility to deliver now.

~~~
Pypie1
At the same time, if I simply had stuck with what I knew over the years I'd
still be doing old ASP...i'd be more miffed as an investor if you had a great
idea but killed it because you did it in vbscript just because that is what
you knew, or if you chose something that would cost a lot more to scale, thus
requiring greater investment just to see a return.

~~~
carbon8
That might be relevant if we weren't talking about modern and very actively
developed web frameworks on modern and quickly evolving languages.

------
rdouble
I've done projects in both Django and Rails. Your list of Rails drawbacks is
weak. The magic can bite you but most of the time it doesn't. Documentation on
any open source project is usually pretty bad. Both Rails and Django have
about the same level of documentation at this point. The API is no more
inconsistent than anything else.

The minus I encountered with Django is that it isn't as far along with the
nice auxiliary pieces that exist alongside Rails. Gems are much better than
easy_install or eggs. Phusion passenger is easier to deal with than...
whatever Django is doing these days. Capistrano is better than Fabric. Heroku
is better than App Engine.

What I liked about Django is that integrating other Python libs was easy, and
some of them are way better than the Ruby equivalents. PIL is way better than
any of the Ruby image manipulation libraries. Django also makes it easier to
do GIS stuff out of the box.

In my experience the REAL problem with rails is that if you're actually doing
high-load transactional sites, like serious e-commerce systems, it is not up
for the task. The successful Rails sites I built mostly had few inserts and a
lot of reads. Tons of transactions == meltdown in ways neither I nor
professional rails consultants understood. Those pieces were ultimately re-
architected in Java (with some JRuby to help out). I'm not convinced Django
would help with a site like this.

------
tptacek
No offense, but how amazing can your idea be if it allows you to procrastinate
on web frameworks?

~~~
shabda
No offence, but why is evaluating technologies which you are going to be stuck
with for a very long time a bad thing?

~~~
mechanical_fish
Because, in all likelihood, worrying that you're going to be stuck with your
initial choice of technology for a very long time is premature optimization.
You should be so lucky.

I have no idea what the original submitter's idea is, but I'll _still_ predict
how it's going to work out: It won't find product-market fit. So it won't need
to be maintained for a very long time. So he might as well just build it with
the framework he _already knows_ , get it over with, and move on to the next
idea.

Anyone want to bet that I'm wrong? If so, please make out your angel checks to
the original submitter.

Moreover, while fretting too much about the apparent greenness of the grass on
the other side of the fence is always a warning sign of procrastination, doing
so when you already have three years of Rails experience and know exactly
where its pain points are is _really_ a sign of procrastination. Just build
the thing already! You will save time by working in a framework that you
already understand. And, if you like, you can use that saved time to _improve_
the bits of the framework that you dislike.

~~~
timr
_"fretting too much about the apparent greenness of the grass on the other
side of the fence is always a warning sign of procrastination, doing so when
you already have three years of Rails experience and know exactly where its
pain points are is really a sign of procrastination. Just build the thing
already! You will save time by working in a framework that you already
understand."_

I don't disagree, but I think I should point out the danger -- this is
_exactly_ how programmers become dinosaurs in the industry.

Next time you feel the urge to make fun of that guy with 20 years of C++
experience, keep in mind that he was probably just working in a framework that
he already understood. One day you look up from your last successful project,
and everyone is 22 years old and coding in Blub. Only those _old_ guys are
working with Rails....

~~~
mechanical_fish
I can't argue with this in general, but it hasn't got much to do with the case
at hand. Worrying about the day when Rails will be a dinosaur technology is an
even _more_ extreme form of premature optimization. And if you are trying to
hedge against Rails' obsolescence, why would you pick Django? Shouldn't you
pick something sufficiently different that it _isn't_ routinely mentioned in
the same sentence?

~~~
timr
I'm not worried about it, and I realize it's a digression. I'm just saying
that if every time you face one of these decision points you go with the
technology that you already know, then you're optimizing for something
different than career longevity, and it will come back to bite you. The point
is that there's always a tension in this industry between learning new
technologies and being maximally productive.

That said, it isn't "premature optimization" to diversify your portfolio of
technologies as much as possible. It's premature to try to guess the Next Big
Thing and use it for your project, but that isn't what I'm suggesting. And in
any case, five(-ish) years ago, you might well have faced the choice between
using Perl and using Rails for a similar project. That decision would have
proved fateful.

~~~
mechanical_fish
_five(-ish) years ago, you might well have faced the choice between using Perl
and using Rails for a similar project. That decision would have proved
fateful._

Let's keep some perspective here. Rails, Django, and the various Perl
frameworks each have their rabid partisans, but they represent fairly tiny
variations on a single theme: Client-server web applications. There is very
little danger in overspecializing in any one of these. You can move from one
to another with ease. They employ similar concepts, by necessity. The HTTP and
the SQL and the CSS knowledge all transfer over. The browser is still the
browser. My god, I _wish_ the browser was changing fast enough that I risked
becoming a dinosaur!

I suspect that there is far more danger of overspecializing in, say, MySQL
than of overspecializing in Rails. Databases are huge, complex beasts with
real differences in their implementation and operation, and they can have
profound impact on the performance of your app. (Just ask an experienced
Oracle DBA. He or she will talk your ear off, as happened here on HN the other
week.) The difference between the various brands of glue that we use to stick
our databases to our web servers? Not as fundamental as we'd all like to
think. The stuff I do today is not much different from what I and my
colleagues were doing in AolServer Tcl in 1999. (Now _that_ is dinosaur web
technology!)

The _real_ danger of becoming a dinosaur happens at a higher level. I'm a
professional PHP programmer now, god help me, but I'm not afraid of missing
out on the Great Django Revolution: When Django is finally ready to call my
colleagues and I, I'll listen, and I'll probably understand what it's saying
because it'll still be speaking the language of server-side web apps. The real
danger is that one day I'll wake up and realize that the interesting problems
have moved off the web server entirely and that all the fun is in standalone
Javascript apps, or iPhone apps, or Microsoft Surface 3.x apps, or Scala
applications embedded in your shoes, and server-side web app development has
become about as exciting as Internal Revenue data processing (which it
resembles in many ways).

When I really want to _diversify_ , I'll look at Javascript or Objective C or
embedded systems programming. I won't look right next door. That's too easy.
Alas, this means that my track record of never getting around to learning
Python may continue. :(

------
benatkin
Here's what I've found so far after starting a small Django gig (I already
knew a fair bit about Rails):

\- Rails has built-in migration support

\- Rails has better support for APIs

\- Django has some neat stuff in contrib including authentication and an admin
interface

\- Django has "pluggables" -- downloadable apps that can be snapped in just
like the admin interface. Rails has engines, but they're new and not as mature
as pluggables.

~~~
mccutchen
> Rails has better support for APIs

What does this mean?

~~~
benatkin
To be specific, Rails has better support for providing XML and JSON APIs. One
place where it has better support is serialization. In rails, there is an
:include parameter to control whether to include objects from associations (e.
g. comments in a post), that is available both on to_xml or to_json. I don't
see an option for Django that does the same thing.

[http://api.rubyonrails.org/classes/ActiveRecord/Serializatio...](http://api.rubyonrails.org/classes/ActiveRecord/Serialization.html)
<http://docs.djangoproject.com/en/dev/topics/serialization/>

------
hyperbovine
You'd be crazy not to use Rails. If your idea is really all that you say it
is, chances are good that someone else has thought of it too. Maybe they are
building it right now, maybe not. First-to-market is practically a sine qua
non these days, and you're talking about spending the next three months
getting up to speed on a foreign technology? If I were you I'd start banging
that puppy out in Rails starting like, yesterday.

------
iamelgringo
It sounds like you want 2 things.

1: Build out your killer idea 2: Learn Django and use it

I don't think the transition from Ror to Django should be that big of a deal
for you. Ruby and Python are similar enough, and the frameworks have enough
conceptual overlap that it shouldn't be that big of a deal for you to switch.

The Django community is very responsive and professional with questions. Posts
on the newsgroup usually get answered within hours, and IRC channel within
minutes.

If you do go Django, may I suggest Practical Django Projects:
[http://www.amazon.com/Practical-Django-Projects-Second-
Benne...](http://www.amazon.com/Practical-Django-Projects-Second-
Bennett/dp/1430219386/ref=sr_1_1?ie=UTF8&s=books&qid=1248030678&sr=8-1)

Also, if you're looking for off shore Django developers, look up a few people
on djangopeople.net.

------
plinkplonk
Look it is just a web app framework. If you know Rails well, you should be
able to pick up Django fast (and vice versa). Sure you'll get a few surprises
in some edge cases, but hey, in the end it is just a framework that mediates
between http requests to databases and generates web pages. How difficult
would it be to grok either once you know the other?

fwiw, I've built apps with both, I prefer Django, But I wouldn't agonize about
switching to Rails for a project or two if required. And no matter how much
advice you get only you can decide which one suits you better and you can
decide that only afer using both in serious projects.

Just start writing code.

------
AhmadH
You can't go wrong with any of them. I think Django has a slight edge by
having a slower release cycle. I find it a desirable quality in a development
framework.

While the number of man-months spent developing Rails is an order of magnitude
greater than that spent developing Django, is it really that much better for
the bottom line?

Most of the early efforts spent on Rails were to make the infrastructure and
community more mature. Even the brilliant DHH was a PHP developer before he
started Rails.

On the other hand, Django benefited a lot from Python's maturity.

~~~
shabda
> While the number of man-months spent developing Rails is an order of
> magnitude greater than that spent developing Django

Wildly off base figure

1\. Years under development. ROR: 5/Django 5

2\. Members in largest google group: ROR 18000+/Django 14000+

3\. Members in Irc currently: Ror 436/Django 401

4\. Commits to repo: Ror ?/Django 11000+

So while Ror has a bigger community, it is not that much bigger.

~~~
AhmadH
There is no easy way to measure this. But to support my point:

Rails first public release: July 2004 (5 years back)

Django's first public release: July 2005 (4 years back)

Rails Contributors: 1350

Django Contributors: 460

I never said that Django's community was smaller. I just said that it was more
mature in their programming language and therefore it was easier for them to
get things done right the first time.

------
llimllib
Desire(learn django) > Value(rails knowledge) ? django : rails

Nobody can tell you what those values are. Both are acceptable frameworks,
just pick one and move on.

------
ericb
Can someone who knows Ruby and Python contrast their metaprogramming
capabilities along with how much mileage Django and Rails get from it under
the hood?

------
idlewords
Without learning a bit more about the nature of your project, I don't think
it's possible to give you meaningful advice. Dish!

------
Pypie1
What about performance and scalability? Doesn't python (with psyco and soon,
unladen swallow) win big here? When you choose a platform, it's important to
choose one that won't limit you when you start having users on a large
scale...

~~~
carbon8
Unless something changed, django doesn't even run on psyco cleanly and the
combo is unsuitable for production. Unladen swallow also isn't ready for use
in production with django and it's unclear when it will be. But performance
from these languages aren't the bottlenecks in web apps, and Ruby 1.9 and
Python 3 have similar performance, anyway.

~~~
mccutchen
> Ruby 1.9 and Python 3 have similar performance, anyway.

That's immaterial in this debate, isn't it? Django doesn't run on Python 3,
and Python 3 is still slower than Python 2 (though they're starting to focus
on performance improvements in Python 3 with every new release).

------
joel_feather
Trust me, Django is almost dead. The hype around Django is completely dead and
existing developers are using it, but new developers are not jumping on ship.
In 6 years there will be a serious Django shortage of maintanance personell.

Stick with rails and don't make the silliest mistake of your life.

~~~
shabda
Any statistics you have to back that up?

