Anyone interested in explaining why I should choose Django over Rails nowadays? Or is this just a Python vs Ruby thing?
- http://www.django-rest-framework.org/
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.
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.
Templating is the most frequently subbed out part of Django. I'm not sure how you'd make it more "pluggable."
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
https://docs.djangoproject.com/en/1.11/
vs
http://guides.rubyonrails.org/
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.
Personally, as a heavy Python user, I prefer Django's explicitness vs Rails more "magic" style.
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).
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.
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!
https://github.com/sferik/rails_admin
I will definitely have to try Rails 5 and see what's up, it looks like I missed a lot over the years.
I would love to know if Django's Admin fares better in this regard.
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.
Yup http://weblog.rubyonrails.org/2017/2/23/Rails-5-1-beta1/
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.