3 ms·

I don’t get why there is so much negativity on Django when Instagram and other large websites still use it. I used it a few years ago for a startup and I liked

I don’t get why there is so much negativity on Django when Instagram and other large websites still use it. I used it a few years ago for a startup and I liked it. It also has a user management system built in also .

jgb1984 5y ago
Where do you see negativity? I've been using it professionally for over a decade, and can highly recommend it. Very mature, polished, fully featured, reasonably performant, well documented and a pleasure to use. A real productivity boost. It's the most widely used web application framework in the python world, which happens to be my preferred programming language.
lucian1900 5y ago
The ORM is the only weak point, the rest is widely considered stable and of quality.
- amanzi 5y ago
  What's weak about the ORM? I've been working with Django for the last year or so and find the ORM great, but I don't have much experiences with other ORMs to compare to.
  - lucian1900 5y ago
    It lacks a unit of work system to allow precise control over loading and saving data. It also lacks an abstraction for composing arbitrary SQL queries out of components. It’s sometimes very difficult to predict the number of queries that will be emitted. It’s a reasonable ORM, but doesn’t compare to SQLAlchemy.
    - theptip 5y ago
      I strongly agree with this; while the ORM is great for simple/medium complexity use-cases, it really lacks the flexibility to extend into more complex domains. SQLAlchemy can hit all the Django ORM's use-cases, and also can be used for a bunch of designs that the Django ORM simply cannot support. A dirty-tracking mode would be great. This is really useful if you want to have code that builds up a list of sub-objects, and then _maybe_ commits them, but maybe rolls back after creating most of the Python objects. The naive Python you want to write is `for i in range(10): foo.bars.add(Bar(i))` which in the Django ORM triggers a DB write for each bar, even if you error out on the 10th Bar. As you say, another area where the ORM can bite you is the always-on foreign-key-traversal logic. So if you have loaded model foo, then accessing foo.bar will trigger a SQL query under the covers, if you didn't select_related/prefetch_related properly. This is great for simple use-cases and exploratory coding, but can make it very easy to write code with horrendous performance. Naively-coded views often have hundreds of DB lookups and it's hard to track down where these are coming from when the app is complex and especially when you've got _some_ *_related in place, but you're missing a prefetch somewhere.
- weird-eye-issue 5y ago
  Django's ORM is pretty incredible actually. I've been able to do some very advanced queries including window functions, several subqueries, even recursive CTEs...
- suvelx 5y ago
  What makes you think it's the weak point? Imo the ORM is easily the best bit. The request-handling and template rendering is in my mind the weakpoint.
  - livre 5y ago
    I agree with this, I've been using Django for more than a couple of years. The built-in admin interface is a blessing, the ORM is good enough and unless you are handling very huge loads it doesn't matter if it doesn't always generate the most efficient queries (in more than 5 years I've never run into any issues with that). The almost but not exactly MVC pattern that also let's you mix both class and function based views coupled with a very limited template system is a curse. I would have preferred one way to do things(TM) but the Django approach let's you badly do a hundred and more different ways if you aren't very experienced with it (and even if you are you need a lot of discipline to do things properly, and even if you have discipline sometimes Django doesn't have a feature you need so you implement your own and then a major release comes and now it has its own incompatible way of doing the same thing). I still wouldn't change Django for anything else, I'm sure I wouldn't have a job anymore if it weren't for how fast and easily I can implement things with it (management is an absolute hell here and changes how everything is done every couple of months until management itself gets fired and replaced every year or two).
bredren 5y ago
Instagram started with Django but today it "uses django" only with the air quotes. Listen to the interview with Carl Meyer https://djangochat.com/episodes/django-instagram-carl-meyer https://djangochat.com/episodes/django-instagram-carl-meyer
- tfehring 5y ago
  Here's the relevant excerpt, lightly edited for clarity and accuracy: > I mean, Instagram server is still a big Python codebase. It's Django at the core, I mean, it still runs through the Django request handling stack, and the middleware and views and URL routing, all of that is still Django. It looks familiar to any Django developer. Just very big, lots of views, lots of URLs, lots of code. There's a lot of, I mean, obviously, the ORM we don't use anymore, the admin is very much based on the ORM, so that's not in use anymore. And there's a lot of components, where Django provides kind of pluggable back ends, like sessions and authentication, and for all of that stuff, we've essentially rewritten the entire system. But we're actually still using the sort of Django API for those things, because it's pluggable. So I would call that a success story, I mean, in that we've been able to very smoothly migrate away from the components that that no longer worked at our scale, in many cases without even having to change the client code touching those subsystems because Django provides this ability to swap out the back end. So yeah, and you know, the Django core requests support that we still use, we're 100% async now, so already a few years ago, we kind of forked and modified a bunch of that to support async, or concurrent handling of multiple requests using async IO. So there have been some changes.
  - bredren 5y ago
    - an old fork that has a custom async support - no use of ORM - no use of admin - replaced sessions - replaced auth I would say it is a Django success story but given how much has been replaced it sounds more like a Python success story to me.
    - singingfish 5y ago
      It's a "let the framework help you write a sensibly structured code base so you can make good decisions ongoing more easily" success story really.

jgb1984 5y ago

Where do you see negativity? I've been using it professionally for over a decade, and can highly recommend it. Very mature, polished, fully featured, reasonably performant, well documented and a pleasure to use. A real productivity boost. It's the most widely used web application framework in the python world, which happens to be my preferred programming language.

lucian1900 5y ago

The ORM is the only weak point, the rest is widely considered stable and of quality.

amanzi 5y ago
What's weak about the ORM? I've been working with Django for the last year or so and find the ORM great, but I don't have much experiences with other ORMs to compare to.
- lucian1900 5y ago
  It lacks a unit of work system to allow precise control over loading and saving data. It also lacks an abstraction for composing arbitrary SQL queries out of components. It’s sometimes very difficult to predict the number of queries that will be emitted. It’s a reasonable ORM, but doesn’t compare to SQLAlchemy.
  - theptip 5y ago
    I strongly agree with this; while the ORM is great for simple/medium complexity use-cases, it really lacks the flexibility to extend into more complex domains. SQLAlchemy can hit all the Django ORM's use-cases, and also can be used for a bunch of designs that the Django ORM simply cannot support. A dirty-tracking mode would be great. This is really useful if you want to have code that builds up a list of sub-objects, and then _maybe_ commits them, but maybe rolls back after creating most of the Python objects. The naive Python you want to write is `for i in range(10): foo.bars.add(Bar(i))` which in the Django ORM triggers a DB write for each bar, even if you error out on the 10th Bar. As you say, another area where the ORM can bite you is the always-on foreign-key-traversal logic. So if you have loaded model foo, then accessing foo.bar will trigger a SQL query under the covers, if you didn't select_related/prefetch_related properly. This is great for simple use-cases and exploratory coding, but can make it very easy to write code with horrendous performance. Naively-coded views often have hundreds of DB lookups and it's hard to track down where these are coming from when the app is complex and especially when you've got _some_ *_related in place, but you're missing a prefetch somewhere.
weird-eye-issue 5y ago
Django's ORM is pretty incredible actually. I've been able to do some very advanced queries including window functions, several subqueries, even recursive CTEs...
suvelx 5y ago
What makes you think it's the weak point? Imo the ORM is easily the best bit. The request-handling and template rendering is in my mind the weakpoint.
- livre 5y ago
  I agree with this, I've been using Django for more than a couple of years. The built-in admin interface is a blessing, the ORM is good enough and unless you are handling very huge loads it doesn't matter if it doesn't always generate the most efficient queries (in more than 5 years I've never run into any issues with that). The almost but not exactly MVC pattern that also let's you mix both class and function based views coupled with a very limited template system is a curse. I would have preferred one way to do things(TM) but the Django approach let's you badly do a hundred and more different ways if you aren't very experienced with it (and even if you are you need a lot of discipline to do things properly, and even if you have discipline sometimes Django doesn't have a feature you need so you implement your own and then a major release comes and now it has its own incompatible way of doing the same thing). I still wouldn't change Django for anything else, I'm sure I wouldn't have a job anymore if it weren't for how fast and easily I can implement things with it (management is an absolute hell here and changes how everything is done every couple of months until management itself gets fired and replaced every year or two).

bredren 5y ago

Instagram started with Django but today it "uses django" only with the air quotes. Listen to the interview with Carl Meyer https://djangochat.com/episodes/django-instagram-carl-meyer https://djangochat.com/episodes/django-instagram-carl-meyer

tfehring 5y ago
Here's the relevant excerpt, lightly edited for clarity and accuracy: > I mean, Instagram server is still a big Python codebase. It's Django at the core, I mean, it still runs through the Django request handling stack, and the middleware and views and URL routing, all of that is still Django. It looks familiar to any Django developer. Just very big, lots of views, lots of URLs, lots of code. There's a lot of, I mean, obviously, the ORM we don't use anymore, the admin is very much based on the ORM, so that's not in use anymore. And there's a lot of components, where Django provides kind of pluggable back ends, like sessions and authentication, and for all of that stuff, we've essentially rewritten the entire system. But we're actually still using the sort of Django API for those things, because it's pluggable. So I would call that a success story, I mean, in that we've been able to very smoothly migrate away from the components that that no longer worked at our scale, in many cases without even having to change the client code touching those subsystems because Django provides this ability to swap out the back end. So yeah, and you know, the Django core requests support that we still use, we're 100% async now, so already a few years ago, we kind of forked and modified a bunch of that to support async, or concurrent handling of multiple requests using async IO. So there have been some changes.
- bredren 5y ago
  - an old fork that has a custom async support - no use of ORM - no use of admin - replaced sessions - replaced auth I would say it is a Django success story but given how much has been replaced it sounds more like a Python success story to me.
  - singingfish 5y ago
    It's a "let the framework help you write a sensibly structured code base so you can make good decisions ongoing more easily" success story really.