mumble grumble previously posted https://news.ycombinator.com/item?id=5666844
933 karma · joined April 2, 2013
Rails - lots of good defaults and conventions that you will not need to change for quite a while. Often leads to the idea of Rails magic which can bite you occasionally. Django - more config up front, but you can sort of fine tune it to your own style and you'll get a better understanding of what's going on behind the scenes.
Rails really enforces a one controller method per resource action - so you have individual actions in your controller for listing, creating, updating, destroying, showing your resource. This is, in part, because routes are automagic in rails - simply defining a resource in your routes.rb will wire up all the CRUD routes with standard names you could wish.
Django doesn't enforce defaults in this respect - you create your urls yourself, defining them with regex, you name them as you wish and you point them to methods as you wish. You can, if you prefer, set up one method for a resource and control all the logic in that method (check for GET or POST, check if its in the db or not, save or update etc).
Rails and Django can both be thought to implement MVC, Django, however, doesn't name it as such - equivalents are: Rails Model - Django Model Rails Controller - Django View Rails Views - Django Templates
Rails will put each resource into individual files - one model per resource, one controller per resource multiple views per resource.
Django tends towards one model file with all your models, one views file with your "controller" logic, multiple template files for your front end.
Django has the concept of "apps" within a project - I find that separating a project into multiple apps helps keep code organised nicely - you can take this to extremes and have an app per resource if you wish or go for a more domain driven ideal and have an app per domain model.
Django is much more explicit - you will write many more import statements than in Rails, where you can go for days (dare I say projects) without doing so.
Rails has built in migrations, for Django you need a bolt on (south).
Rails is a "migration first" approach. Django is a "models first" approach. By this I mean Django has explicit model definitions that you will write by hand. With Rails you will write a migration to define your models and let Rails create the explicit canonical version of your database definition (schema.rb).
With Rails, you'll quickly get sucked in to RVM or rbenv or similar to handle your ruby versions and gemsets. With Django, you'll use virtualenv.
I think the one you choose is basically down to how you view your code - if you go with Rails, fall in line with the Rails way and you'll be good to go. Don't try to buck the trend in the first instance and follow the community conventions - it's quickest to get going with rspec, even though the official docs use minitest/testunit for testing, just because there is more written about rspec out there, more examples in the wild etc. Django is great if you want more flexibility out of the box, but it comes with a price - you can tangle your code because you aren't guided quite as much as with rails. You'll spend more time considering your routing (this is good and bad).
From my perspective, I got more of an app up and running with Rails than with Django in an equivalent amount of time. But with Django I ended up with a more complete "map" of my app in my head than with Rails - for example, with Rails there's a kind of "I have a concept of books in my library, I want to add a new book so I click add....rails magic.....I end up in my new action in my controller and it (magically) renders my new.html.erb view" - the equivalent for me in Django would be "I want to add a new book so I click add and it hits my urls file and finds the route I've declared that points to my book_new function in views.py that explicitly renders my template". There's lots of Rails magic. But it's good magic. There's less Django magic, but that's also good. :)
By contrast, ASP.NET MVC is sort of inbetween the two - You declare your models explicitly, as you do in Django, it writes migrations for you from the models. The routing and view rendering is more akin to Rails than Django. However ASP version has strongly typed views (which really help with autocomplete) in contrast to both Rails and Django. It's actually fairly pleasant, though because C# is strongly typed, you'll end up with more code in general.
It can be disheartening, because when I'm looking for work, I also spend a lot of time on applications and generally only apply to one or two companies at a time so I can devote attention to the interviews et al. Also I'm not usually looking for any job so trying to hit as many companies with my CV as possible is not my modus operandi, but it feels like that would be more appropriate, or at least get a better rate of return on effort applied to the process. :/
from my side of the table, when I was interviewing (about 6 months ago), probably 8 out of 10 startups that I applied to and interviewed for didn't bother to contact me again - not even a polite "thanks but no thanks". I'm not arrogant enough to think I'm the perfect fit for every company I apply to or even that I aced every interview, but I would think common decency dictates at least a response or acknowledgement after an in person interview.
Two sides of the same coin, in my opinion.