9 ms·

Ask HN: State of Django vs. Rails?

• bayesianhorse 14y ago
  You don't see anything comparable to Pandas, Numpy or Scipy in Rails. Yes, there's SciRuby, but they aren't quite there yet.
  • gourneau 14y ago
    This is a great point. I work in biotech, and we use Python because of increasingly rich scientific tools available for Python. This makes Django (or another Python framework) the clear choice, just because it is Python. Think about the whole language ecosystem. Django is just Python. SO has 165,076 post tagged for Python. Just 65,706 for Ruby. P.S. We are hiring Python/Django devs in SF. Email me if you are looking for a gig :) You get to work on a open source this project : https://github.com/iontorrent/TS/tree/master/dbReports https://github.com/iontorrent/TS/tree/master/dbReports
  • Legion 14y ago
    That's a very compelling reason to use Python if you need those things. On the flip side, RubyGems is much bigger than PyPI and has a lot of modules that you won't necessarily find equal counterparts to in PyPI. I think there's a lot of use cases one can come up with where one language's library offerings suit them better. That was how I chose between Ruby and Python. I chose Ruby+Rails but it very, very easily could have been Python+Django.
• kyllo 14y ago
  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.
  • meric 14y ago
    Yes, but the app ecosystem not so much.
  • makaimc 14y ago
    Yes, Django 1.5 supports Python 3 although the authors recommend waiting until 1.6 for production sites (https://www.djangoproject.com/weblog/2012/aug/19/experimental-python-3-support/ https://www.djangoproject.com/weblog/2012/aug/19/experimenta...). The larger question is whether the libraries you want to use support Python 3. Common libraries such as django-debug-toolbar unfortunately do not yet support 3 (https://python3wos.appspot.com/ https://python3wos.appspot.com/).
  • keypusher 14y ago
    To be fair, very few projects from the Python ecosystem have been eager to jump to Python 3.
  • lawnchair_larry 14y ago
    The whole Python 2 / Python 3 incompatibility issue was one of several reasons why I decided to focus on learning Ruby and Rails instead. Although I understand that mentality and share it on some level, that was a bad way to make that decision. If you write Python 2.7 and avoid things marked deprecated, you are nearly compatible with Python 3 by default. Besides, this one isn't Django's fault.
  • FireBeyond 14y ago
    "The whole Python 2 / Python 3 incompatibility issue was one of several reasons why I decided to focus on learning Ruby and Rails instead." Confused. It seems, and I'm happy to be corrected, that many new Rails versions deprecate, often with little notice, even core components. Or am I wrong?
    • Buzaga 14y ago
      Yes this happens. But the point is that Rails and its community like to stay on the edge, if something deprecates you fix and it's done... the thought of framework developers trying too hard to be compatible with everyone's apps, people backporting language features to an older version so they don't have to switch and a popular framework dragging the evolution of a language is much more worrisome to a lot of developers I'm not entitled to talk about Django but that's my perception... There was a really funny comment in a thread like this back then that impersonated Rails saying "New Ruby version? let's deprecate everything!" and Django going "On the weekend we're gonna discuss making Django compatible with the 5 year old Python" And then someone said "What I like about this comment is that it pisses off both sides of the table" :p
• jacobian 14y ago
  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.
  • rednukleus 14y ago
    > If you don't know either, take a <em>week or two</em> and build a site with both and see what sticks. If only we were all this talented.
    • dnsauve 14y ago
      I don't see why this isn't good advice. This is exactly what I did when I was trying to decide between the two. It really doesn't take long to work your way through the introductory tutorials to get a feel for which framework and language you prefer.
      • rednukleus 14y ago
        I've been learning Python and a bit of Django, and it has taken me a lot longer than 2 man-weeks to get to grips with it. I can't imagine that I would be able to learn enough Ruby to give Rails a good shot in two weeks. I'm absolutely sure that there are many developers out there that can pick these frameworks up that quickly, but I'm equally sure that there are plenty of developers who "aren't that talented".
        • markokocic 14y ago
          After learning a couple of (different) languages, learning the new one is easy. So easy that it usually equates learning its standard library. So learning either Django or Rails, if you are moderately experienced developer shouldn't really take more than a few weeks. Of course, learning the first language is challenging.
• jarrett 14y ago
  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."
  • rednukleus 14y ago
    You left out the differential in the availability of books. In my experience, Rails has a larger online community, but Python has more printed books. I think this is a product of the speed at which Rails develops - it is more likely that a Rails book will be outdated by the time it is finished than a Django book.
    • IgorPartola 14y ago
      Also jobs. The following are searches for "Ruby on Rails" and "Django" in New York, NY Ruby: - indeed.com - 507 - monster.com - 66 - dice.com - 96 Django: - indeed.com - 242 - monster.com - 30 - dice.com - 65 Edit: formatting Edit 2: Though you could argue that Ruby is mostly used as Ruby on Rails, while you could search for "Python" jobs if you have experience with Django. Edit 3: what is with the downvotes? If you want to learn a new framework whether you can get employment is something to consider.
• marcrosoft 14y ago
  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.
• deleted 14y ago
  [deleted]
• obviouslygreen 14y ago
  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.]
• jspiral 14y ago
  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.
  • squidsoup 14y ago
    I have been enjoying working with Django Rest Framework (http://django-rest-framework.org/ http://django-rest-framework.org/) recently. It has a less magical approach than TastyPie and uses Django conventions like class-based views. My favourite feature is that the framework generates a web interface, making the API browseable (http://restframework.herokuapp.com/ http://restframework.herokuapp.com/).
    • 14y ago
• danso 14y ago
  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?
  • tholex 14y ago
    Python's Flask is a superb Sinatra clone, and Django's ActiveRecord equivalents are equally useful in Flask, especially for Mongo. Flask sits on top of Werkzeug, which is similar in power and use cases as Rack - middleware, fine-grain auth, etc.
  • civilian 14y ago
    You can swap out Django's built-in ORM for something else (like SQLalchemy) and you can also swap out the django templating for something else if you want. Flask http://flask.pocoo.org/ http://flask.pocoo.org/ is pretty awesome and I've used it for a project that was really light on server-side code (http://palettecomp.com/ http://palettecomp.com/), but I've never used Sinatra so I don't know how it compares.
    • r4vik 14y ago
      Flask is basically exactly the same as Sinatra
• larrykubin 14y ago
  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.
• mkadlec 14y ago
  Is Django/Python going to get rid of the double underscore convention? If so, I'll switch from Ruby/Rails... :)
  • lclarkmichalek 14y ago
    It's not a convention, it's part of the language.
    • mkadlec 14y ago
      I know, that the worst part! I like Python, in fact the indentation convention makes it really nice to read, but why did they uglify it with the double underscores?
• eedeep 14y ago
  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-djangonauts/ http://blog.jupo.org/2011/07/30/rails-quick-start-for-django...
• jayferd 14y ago
  It's more like Python toolchain vs. Ruby toolchain these days.
• ersoft 14y ago
  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)
  • LeonidasXIV 14y ago
    > Most Django libraries handling authentication stick on default User class, so it's difficult to subclass it if you require custom fields. This has been fixed in the upcoming Django 1.5. I don't want to argue with you, just point out this tiny detail.
• hcarvalhoalves 14y ago
  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.
• sergiotapia 14y ago
  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?
  • guoxiaotian 14y ago
    with Ruby 1.9 you don't need the '=>' for hash values: class Person < ActiveRecord::Base attr_accessible :first_name, :last_name validates :first_name, length: { maximum: 30 } validates :last_name, length: { maximum: 30 } end
  • aGHz 14y ago
    You are probably trolling, but just the same, I don't like it when people get downvoted without explanation. Ergonomically speaking, count the number of characters that need to be input by holding the shift key, and that will tell you which is simpler to type. edit: Well when I started replying, you were well into the light grey and with no reply.
    • sergiotapia 14y ago
      Just because you do not agree does not mean I'm trolling. Don't do that here on HN.
      • aGHz 14y ago
        I didn't mean it as an insult. But when you make a statement then provide an example that contradicts it, that's usually a troll move. Ergonomically speaking, the example you provided is easier to type for Django than Rails. Again, didn't mean to offend.
• icn2 14y ago
  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.
  • beatpanda 14y ago
    There's a comparable facility that's part of Django best practices, but it's not bundled with Django. It's a pip requirements.txt file. Substitute 'bundle install' for 'pip install -r requirements.txt' and it's basically the same thing.
    • aGHz 14y ago
      It bears mentioning that this is usually done in conjunction with virtualenv. The common practice is to include a requirements file in your repository, and have every repo clone live in its own virtualenv. This is something I very much love in the Python world: encapsulation of deployments is separate from package management.
• kennu 14y ago
  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.)
• beatpanda 14y ago
  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.
  • jarrett 14y ago
    > canonical definition of a model's database schema...I'm still not sure where to look for this in Rails. db/schema.rb has that. > 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. I have found that to be difficult too. It think it's because Less has fallen out of favor, and SCSS is the new standard. It's actually super easy if you're willing to use SCSS. You mentioned Django plugins providing an asset pipeline. Do you feel that it's easier to start supporting a new asset type in Django's pipeline than in Rails'?
    • beatpanda 14y ago
      > LESS has fallen out of favor Eh, I don't know, Twitter bootstrap users don't appear to agree. I know it's fallen out of favor for DHH, but I don't know if that's generally true. > You mentioned Django plugins providing an asset pipeline. Do you feel that it's easier to start supporting a new asset type in Django's pipeline than in Rails'? No idea, because I've never tried to do it, but the one I was referring to seems to make it pretty easy: http://sunlightfoundation.com/blog/2011/01/20/django-mediasync_2/ http://sunlightfoundation.com/blog/2011/01/20/django-mediasy...
• iends 14y ago
  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.
• nobleach 14y ago
  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.
• smonff 14y ago
  Please check this WikiVS page www.wikivs.com/wiki/Python_vs_Ruby.
• lukasko 14y ago
  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.