Django has advanced significantly over the last five years. It's definitely worth a look if you haven't tried it in a while. A few things to start with:
I recently posted about why I dislike Rails. For a long time, I also disliked Django, for somewhat similar reasons. [0]
The biggest thing that I disliked about Django was its templating system. Its attempts to magically render values were (and are) offensive. When I looked before, just like Rails, it was take it or leave it, and there was little sympathy for making it pluggable.
Such issues, and the culture's Rails-like resistance to outside suggestion and interoperability, pushed me into Pylons/Pyramid.
Today, I think Django has improved a lot, and I don't think it's fair to continue to lay the pox of being "Rails-for-Python" on it.
Django now supports third-party templating engines (so the dealkiller is gone) and last I checked, the SQLAlchemy integration, while not official, is much better. They now have Python 3 support and as pointed out here, will be going Python 3 exclusive soon.
I've submitted a few bugs and they get triaged quickly. I had a patch or two merged. Pretty happy with that. The Mezzanine guy is also great about this stuff.
Django does follow the old-school big magic model, but I haven't encountered much [recent] trouble in working around that. The community does not seem to respond negatively to such suggestions anymore.
People say it comes down to Ruby v. Python, and I think that's true, but in a different way than most. It comes down to the core culture of Ruby v. Python.
As the MVC framework hype and subsequent noob-influx died down, Django was left with the core Python community of mature hackers who've developed a refined palette for simplicity. This has been Django's biggest asset, and has turned it into something that's worth using today.
Disclaimer here: I was not then, and I am not now, super deeply involved in Django, either the product or the community. This is primarily based on my impressions from light observation and use. Some/much of it could be wrong.
I'm using Pyramid on a daily basis. I'm very happy with how everything performs. Things never get in my way and SQLAlchemy is awesome ORM solution. For me pyramid is the sweet spot between microframeworks and django.
The team that manages Pyramid is extremely competant, I've updated my applications over multiple releases without issues over the years.
I think what people use often depends on weather you prefer to have choices being made for you with tightly coupled systems vs sane defaults that you can customize to your liking.
> The biggest thing that I disliked about Django was its templating system. Its attempts to magically render values were (and are) offensive. When I looked before, just like Rails, it was take it or leave it, and there was little sympathy for making it pluggable.
Templating is the most frequently subbed out part of Django. I'm not sure how you'd make it more "pluggable."
They made it so that you could still use django's "render helpers" and things like the middleware directly, and just replace the 'render the template file' part.
Before you could always call a third-party rendering library, but it usually meant you wouldn't get things like the Django context renderers or template file lookup by default
Mostly Ruby vs Python, though I think that's a big distinction. Rails is Ruby's killer app, but Python has killer apps in many things, so if you want to integrate something else (like Machine Learning for example) easily into your code, then Django (because it is Python which has a lot better support for ML) makes that so much easier.
Also looking at the footer of each site, the Django one screams 'inclusive community' which I think is a positive signal in terms of its future growth.
Mostly a Python vs Ruby thing. Both are pretty mature frameworks of roughly the same age, so for the most common use cases it doesn't make a ton of difference.
Personally, as a heavy Python user, I prefer Django's explicitness vs Rails more "magic" style.
This will likely be controversial, but IMO both frameworks will "go wrong by default" if your codebase/feature set/team working on it start to get large, and rails is worse. There is no real modularity of features or services encouraged, you by default just have a big bag of models with all sorts of implicit couplings because they're all hooking into each other's public ORM methods and lifecycle hooks and it becomes a nightmare.
By using lighter weight frameworks you're forced to build parts of your own framework in some ways, which can be a bit more work in the short term, but that means it can be optimized for your domain and you can do more to set up explicit boundaries/document how the team should use things. You can also do this in rails/Django, but then you start ignoring the built-in stuff that made them popular in the first place, and there is such a strong idea of "the rails way" that it'll be hard to get buy-in to diverging from that.
OTOH if you're building something that has a pretty moderate scope and aren't worried about it getting too big, both will get the job done fine.
As additional points, rails is also quite a bit slower, and python is honestly a more versatile language than ruby these days (if you want to pull in any ML or scipy code there are obviously a lot more python options).
> There is no real modularity of features or services encouraged...
I've used multiple apps per Django project for grouping and isolating features. The Two Scoops book lays out a nice project architecture for doing this, and some people take it as far as to deploy separate Django apps within the same project as separate services.
Yeah it's certainly possible, in both Django and Rails. But I'd still argue that both frameworks lead you astray by default unless you consciously go against the grain to avoid it.
It boils down to Python vs Ruby. Overall, both frameworks are pretty similar and you can build a modern web application in both.
Personally i think RoR is the slightly better framework (better defaults, easy test/dev/production setup, sane asset handling), but i prefer Python over Ruby, so i end up using Django.
Edit: What a long strange trip it's been. According to my old bookmarks, wycats developed a rails admin module about 10 years ago (code not available today). I discovered that he also worked on Merb, sort of a fork of Rails, and then after helping to merge that back into Rails, he helped sferik port MerbAdmin to RailsAdmin, which exists today!
Just a heads up: Admin gems are only suitable for projects that are simple and stay simple. If you want to do something that's not provided by your admin gem, you'll be fighting it. I have gone through that arduous path myself multiple times, only to end up rewriting everything from scratch.
I would love to know if Django's Admin fares better in this regard.
I've used the Django admin in pretty much every production project I've touched. It's the bees' knees. There's some customization overhead that becomes higher than doing your own thing is you really want to make your own admin views, but at that point nobody's stopping you from making dashboards from scratch.
Rails uses an asset pipeline package called sprockets. You throw everything in a special directory and it wraps it all up and packages it nicely for you. This also gives you SASS and coffee compilation by default.
Sprockets handles minification and cache invalidation for you.
If you don't mind the opinionated approach to your javascript and stylesheets, it works fine. If you just need to sprinkle in some javascript on top of your site, it's fantastic. If you intend for your app to be javascript heavy, a lot of people rip out sprockets altogether and fallback to webpack to handle asset compilation (and I believe the newer Rails version is integrating webpack to play nicer with the rest of the framework)
I can speak from personal experience that Sprockets is a PITA if you want to use npm.
Rails' philosophy is "convention over configuration", which means there's a lot of what might be called "magic" and it's less clear how to override defaults.
Django adheres to a more "pythonic" approach in which transparency is valued and it's better to be explicit than implicit. More things are documented and configurable.
While Django does have a certain way it expects you to do things (especially in the sense of where boundaries lie between modules), I find that that's at a higher level of abstraction than Rails, where convention rules down to the level of URL structure.
