Ask HN: State of Django vs. Rails?

You don't see anything comparable to Pandas, Numpy or Scipy in Rails.

Yes, there's SciRuby, but they aren't quite there yet.

Is Django 1.5 finally going to support Python 3? Python 3's been out for what, 5 years now, and the major web framework for the language still doesn't support it yet?

The whole Python 2 / Python 3 incompatibility issue was one of several reasons why I decided to focus on learning Ruby and Rails instead.

Obviously I'm totally biased and you shouldn't listen to me.

But if you were to listen to me, I'd probably be saying something about how they're basically equivalent these days. Both are pretty productive, have clean readable code, are well-documented, have active communities, a wide array of plugins and tools, and are fairly easy to use.

If you were to get even crazier and try to get some advice on which you should use, I'd probably tell you that Rails is best if you already know Ruby; Django if you already know Python. If you don't know either, take a week or two and build a site with both and see what sticks. Either way you'll be pretty happy.

But you shouldn't listen to me because I'm heinously, terribly biased, so you probably didn't hear me say any of that. Just as well.

Let's look at some metrics of maturity and community size.

Django and Rails are almost the same age. Rails is only a year older, which doesn't mean much after so many years have passed.

The numbers of Google search results for "Python Django" and "Ruby Rails" are on the same order of magnitude, with Rails having around 50% more. Likewise for "Rails site:github.com" and "Django site:github.com"

The differential is bigger on Stack Overflow, with Rails having about twice as many tagged questions. They're still on the same order of magnitude.

One could of course do a feature-by-feature comparison, but I don't find those particularly useful when looking at frameworks. That's because a framework is a long-term investment. You're not just buying into the current or upcoming version, but all future versions. (Unless you make the expensive choice to switch.) If one has a feature that turns out to be really useful, there's a very good chance the other will acquire that same feature soon enough. Especially considering the size of the Django and Rails communities.

Will Django 1.5 or Rails 4 will change the balance significantly? My guess is not. It's like an arms race: One side or the other may claim the advantage from time to time, but with plenty of smart people working on both, cross-pollination should ensure that they stay fairly comparable.

All that being said, I prefer Rails (largely due to Ruby) and am quite happy with it. Though if I were doing scientific computing, I'd take into account what bayesianhorse said.

It's also worth considering that the whole paradigm underlying Django and Rails, wherein you render a bunch of HTML with your choice of backend language, may not last forever. With the client side getting heavier over time, the advantages of sharing code across client and server may push the mainstream away from Ruby and Python. Or not. This isn't a prediction; more like a "what if."

  Ruby:
    - indeed.com - 507
    - monster.com - 66
    - dice.com - 96
  
  Django:
    - indeed.com - 242
    - monster.com - 30
    - dice.com - 65

I like them both but I have to say Django updates have been easier to deploy than Rails updates. Something always seems to break when I upgrade Rails.

I think the whole "x vs y" idea of Django and Rails is unnecessary. They serve similar purposes but they do it in different ways (the most notable of which, obviously, is the language they use), but comparing them is a questionable pursuit.

If you already have a preference between Python and Ruby, for whatever reason, then your choice is probably already made. If you don't, more important than attempting to build something in both -- which won't really help unless it's something real-world and in-depth, which is unrealistic -- might be to consider the languages themselves and decide which better suits the way you think/code.

Of course, if you have a specific project or set of projects you're looking to build, reviewing the available libraries for the languages and frameworks as well as their maturity and prevalence would be important.

If you're wondering which suits you better as a long-term time investment, reviewing the community and the doc/misc websites surrounding both frameworks would be a good idea. People are pretty opinionated about those particular communities; trying to decide which you find more helpful or have an easier time gleaning information from and/or interacting with could prove valuable in terms of deciding which language/framework would work best for you.

I guess this is a long-winded way of suggesting this is the wrong question; it just isn't meaningful. You could attempt to compare them on all sorts of metrics, but despite their similarity of purpose, I think you're likely to find your own subjective review vastly more useful than anything else.

[edit: This is also intended as a mild indictment of the question, as specifically disqualifying other mature web language/framework combinations does everyone a disservice, though to include them all would make the question even less meaningful.]

I've been doing a ton of work in both recently. In particular, i've been the lead dev on a new product for web and mobile in django, an API layer supporting an iphone app over an existing SQL server database in rails, and a rewrite of the backend for some kiosks in rails, on top of various contributions to other people's projects.

I want to make some comments on writing APIs in particular, since I've been doing a lot of it lately, as my projects almost always have several interfaces these days, e.g. native mobile apps, angular.js web frontends, and as I mentioned above, fat clients running on kiosk hardware.

Building json apis in rails is a pleasure. My mini stack inside of rails is controller -> request handler -> model layer + external services -> rabl. Very clean, few lines of code, easy to maintain, does exactly what you want.

Doing the same with default django is a little less obvious. Tastypie is cool but when you get much beyond providing CRUD over the web to your models, it gets messy. Forget nesting stuff more than one layer deep. In the end, I build a controller layer that matches the way rails works and it's just about as nice, but I have to know and follow the conventions myself.

In particular, i'm copying rails style validators for models, I've built something similar to my rails request handlers using django forms to handle input, and i've built a simplified controller layer that handles routing, paging, filtering, sorting, etc. Instead of rabl, I just write a to_dict function to package data into a response. not quite as slick, but roughly equivalent.

I had to do more on the django side to get there, but at this point both are equivalent for me in terms of building APIs.

I understand that these days there are compelling arguments for building APIs in neither of these languages. However, for speed of development, ease of also putting up a vanilla web interface, and richness of the ecosystem as a whole, I still like django and rails for building mvps.

A related question: what is the state of Python's lighter frameworks versus Ruby's Sinatra? I haven't used Rails in awhile, but since ActiveRecord, ActiveSupport, etc have been refactored into framework agnostic libraries, I've been able to build lighter websites using Sinatra or Padrino (which sits atop Sinatra) using my Rails experience. And of course,Rails itself has allowed for components to be switched in for their AR equivalents, e.g. MongoMapper

How swappable are the core components of Django?

My reasons for using Python frameworks (Django or Flask) are pretty simple:

1) I find Python code easier to read and 2) Rails seems to evolve a bit too fast for me. I find it easier to keep up with Python frameworks.

Is Django/Python going to get rid of the double underscore convention? If so, I'll switch from Ruby/Rails... :)

It's more like Python toolchain vs. Ruby toolchain these days.

As a both Django and Rails developer I suggest you to choose Ruby on Rails.

Rails pluses:

- Has a nice asset pipeline (automatic conversion of CoffeeScript, Sass, Haml, Jbuilder, etc) and concatenation + mignifying.

- Really configurable database migration with a nice DSL. (Django has South which auto generates migration files, but It isn't just as easy to change them)

- Rake tasks (Django also has management commands, but It's easier in using rake)

- multiple environments (development, production, testing), being able to store different configurations (Django does not have this, you can achieve this using some hacks)

- Railscasts.com (great screencasts by Ryan Bates)

- Better release circle, as long as I know in Django didn't appear many features since 1.0 (mostly bug fixes and Python 2.x deprecation warnings)

- more OOP than Django, it really follows MVC pattern, Django is a MVT (Model View Template framework)

- More libraries and more complex and configurable than django libraries. Most Django libraries handling authentication stick on default User class, so it's difficult to subclass it if you require custom fields.

- Model hooks and scopes (I know django has model hooks but they are built using Django signals, not using nice DSL as in Rails)

- Concerns inclusions which guides you to a clean coding style.

- Controller before_filters (very useful when you want to run a filter before multiple actions, eg: check if user is logged in), I know it can also be done using Django middlewares.

Django pluses:

- Django admin (Rails also has a few plugins which try to implement this, but django's is built in and also well documented in their official docs)

- Django built in authentication system (Rails comes with devise library and other alternatives, which is great but not built in)

- Easier to learn (Django follows Python's Zen, "Explicit is better than implicit.", all classes or methods you use must be imported, Rails pollutes global namespace with all classes and namespaces imported from libraries when Gemfile is parsed). It is easier to learn which module each class comes from and it helps you a lot at debugging if you are a begginer.

- Django middleware (you)

- Form based validation (each model can be validated using form class, another minus for Rails is that there was some security vulnerabilities targeting mass assignment on Models)

These frameworks have use cases different enough for this comparison to not make sense.

Although you can build a product using any, Django is out-of-the-box more useful for building publishing platforms or content-heavy sites, while Rails is more about scaffolding and REST APIs.

There are also the obvious differences between the language stacks, libraries available, etc. This may be more important than frameworks themselves, which are mostly glue logic.

COMPLETELY 100% unscientific, but in my glances and reading of the Django docs I found that they make heavy usage of symbols such as [, ] in code.

I like Ruby's terseness. Fewer keystrokes is a win for me, especially when you have a shit keyboard (pardon my french).

Django feels very CakePHP-y, if that makes any sense?

QUICK DUMB EXAMPLE:

Django:

    from django.db import models

    class Person(models.Model):
      first_name = models.CharField(max_length=30)
      last_name = models.CharField(max_length=30)

Rails:

    class Person < ActiveRecord::Base
      attr_accessible :first_name, :last_name
      validates :first_name, :length => { :maximum => 30 }
      validates :last_name, :length => { :maximum => 30 }
    end

---

Which is simpler to type, ergonomically speaking?

    class Person < ActiveRecord::Base
      attr_accessible :first_name, :last_name
      validates :first_name, length: { maximum: 30 }
      validates :last_name, length: { maximum: 30 }
    end

You might find this post from Stephen MacDonald useful if you're thinking about taking the Two Week Challenge (or the One Week Challenge if you're already familiar with one and want to try the other): http://blog.jupo.org/2011/07/30/rails-quick-start-for-django...

I have more experiences on django. Recently I looked into ruby on rails and I don't want to look back. * bundle install. In ruby everything is a gem when you deploy to a new machine all you need to do is "bundle install". In django I really don't see a comparable facility. I recall I forgot something until I got an "import module error" * scaffold. ruby on rails scaffold just makes development usper fast. * dev/test/production config. Well it is just very convenient. * db migration. migration make db update/change much easier. Changing db/data schema is so painful in django.

Rails currently wins if you want to make a "typical" web application, which allows people to sign up with email/password/Facebook. Implementing these things with Django requires uncomfortable tweaking, because custom user models have not been available until Django 1.5 (still unreleased).

It is also very painful to make asset pipelines work in Django (SCSS & CoffeeScript compilation and minification). There are various solutions which require various amounts of tweaking, and which can break in unexpected ways on SCSS syntax errors etc. In Rails, all this just works out-of-the-box.

And lastly, Django's app ecosystem is very tied into the Django ORM data model, which is currently very tied into MySQL/Postgres. If you want to use MongoDB (with MongoEngine), most existing Django apps won't work with it. On the Rails side, Mongoid is an established ODM, and there are existing gems to make most things work with MongoDB without any tweaking. This means you will have the email/password/Facebook authentication (Devise/Omniauth), RailsAdmin, CanCan permissions etc. working right away, and your whole web app can run on MongoDB if you want.

So, even though I'm a long-time Django user and fan, I think it just hasn't kept up with the times. Nowadays Rails works better and is more productive for typical new web projects. (But realtime/single-page-apps are a different story, there I lean towards Derby&Meteor.)

I prefer Django for the same reason I prefer Python — Django is more explicit, there's less 'magic', and it's easier to figure out what's going on when something goes wrong.

One example is model definitions — in Django, the canonical definition of a model's database schema is in an app's models.py file. I'm still not sure where to look for this in Rails.

Additionally, other tools you decide to use with Django don't require any extra "Django magic" to work — they work the same as they would if you used them alongside any other tool.

One example is using Less with either framework. Using Less's `less.watch()` functionality, which enables live updating in the browser based on changes in your .less file, is much more difficult to use in the Rails asset pipeline, in my experience.

There's pretty much feature-for-feature parity at this point, and where it doesn't exist there's a plugin or other supplemental tool. For Django, pip, south, and django-mediasync cover for bundler, migrations, and the asset pipeline (sort of). And of course there's a rails admin gem.

But these are the same tradeoffs that have always existed, and I don't think any of them have changed in the new versions.

I'm a python/django developer. If I could do it over again (ignoring the fact I've basically switched to an all javascript stack outside of work), I would go with rails/ruby.

I think there are more rails jobs than django jobs, at least the type of job I want, and especially in my geographic area (North Carolina).

I feel like the ruby community is much larger, much vocal, and many of the startups I actually buy stuff from use ruby.

I imagine the tooling is pretty compatible, but I'm not that familiar with the ruby world. At the startup I used to work for we deployed django on heroku much like one would do in the ruby world.

One thing that rarely gets brought up is deployment. If you're in a shop with Windows webservers. Django pretty much isn't going to happen for you. I remember a couple of years ago there was some effort toward a WSGI module for Apache based on Cygwin or something.

I'm a huge advocate of JRuby. It's Ruby for the JVM. Consider the fun of getting to write Ruby, and the joy of knowing you can deploy to anywhere with a JVM. I'm not a Windows fan by ANY stretch. I do all my development on my Linux laptop... but the powers that sign the checks think Windows is swell. So consider where you'll be deploying.

Please check this WikiVS page www.wikivs.com/wiki/Python_vs_Ruby.

Compared to Django I find the Ruby tool chain to be much more polished. Getting things working on Django requires a lot of tweaking and tinkering.