5 ms·

The whole appeal of Django is that you can just swap in a different templating engine / syntax if you prefer. And you can add a DB and let there be managed by

The whole appeal of Django is that you can just swap in a different templating engine / syntax if you prefer. And you can add a DB and let there be managed by some other system. Same goes for extending manage.py I’ve worked on Django projects big and small and generally the speed are which we could deliver even on strange edge cases impressed.

mostlysimilar 2y ago
You can do that with Rails too. The difference is that Rails defaults are very good.
- aerhardt 2y ago
  The Rails dev says that Rails defaults are very good and so says the Django dev about the Django defaults. The Django ORM is loved by tens, maybe hundreds of thousands of Python devs globally, and while I could raise concerns about it (for example, the async experimental capabilities fucking suck, and the core dev team is extremely slow to innovate on them on the basis that that's not "the Django way"), I've never heard anyone but a Rails dev complain that it's "too verbose". People love it so much that they'll do atrocities like import it into Jupyter notebooks or simple scripts that should otherwise have no business in bringing in those type of dependencies. I should know because when I've felt creative and a bit naughty about doing those types of things I've found out - to my unmeasurable disappointment - that there were many other trailblazers before me to write gists, Medium articles, and almost everything every type of format short of an entire O'Reilly book on how to do it.
  - deaddodo 2y ago
    > I've never heard anyone but a Rails dev complain that it's "too verbose". Maybe not too verbose, but there's a large population of python devs that find SQLAlchemy (+ Alembic) the much better option.
    - kshahkshah 2y ago
      That's curious to me honestly. I really prefer the ergonomics of Django's ORM compared to when I've had to use SQLAlchemy+Alembic in the past. I find alembic incredibly confusing and poorly documented. Not that documentation matters as much nowadays with AI
      - agumonkey 2y ago
        yeah, alembic feels especially "small" and obscure compared to the hyper exhaustive nature of SQLA for everything else. felt like a side project at first
      - gmassman 2y ago
        Alembic is certainly a bit of a challenge to grasp at first, especially if you want to do anything more complicated than create or alter tables. However, it does provide a great amount of flexibility if you want to implement more complex migration functionality. It allows library developers to add powerful features that would be very difficult to do with Rails/ActiveRecord or Django ORM. FWIW I maintain the flask-audit-logger package. It allows users to maintain audit logs of specific tables using postgres triggers. Being able to create custom migration operations is really an amazing feat. The alembic docs are quite dense, but the code is well organized and very readable.
    - irjustin 2y ago
      Yeah SQL Alchemy is 1000x better. Django's ORM is miserable. User.objects.filter(company__product__product_variation__var_type__in=['var1', 'var2']) vs User.where(company: { product: { product_variation: { var_type: ['var1', 'var2'] }}}) Little things like that make it so much harder to read.
      - globular-toast 2y ago
        Not to mention SQLAlchemy supports the unit of work pattern meaning you can update many objects at once. It tracks and figures out how to apply the updates all in one go. Django supports one object at a time. With SQLAlchemy it's easy to build mappers to real domain objects that are independent of the database. Most Django people treat the Django models as entities or, worse, do business logic in views etc. It's possible to implement unit of work on top of Django, but that's then another layer you have to maintain yourself (which SQLAlchemy does for you). But SQLAlchemy is harder. It's better but it's harder. Django is easier to get going with. But it bites you later (unless your app is just CRUD, in which case Django is all you need, well that and a better way to generate HTML).
  - adammarples 2y ago
    Actually the dango dev is saying that the whole appeal of dango is that you can swap the defaults out easily, kind of the opposite
    - globular-toast 2y ago
      The problem with Django is not swapping out defaults. The problem is it doesn't like to sit at the edge of an application where it belongs. Django should be equivalent of any other MVC-style framework (like Qt etc), sitting right out in the "interface" layer of your software. But it just doesn't work well out there, mostly due to how tightly coupled it is with its ORM.
      - robertlagrant 2y ago
        Django isn't that, though. That would be something like Flask. Django is batteries-included for one (broad) purpose: you are going to use a relational database to make a CRUD app and we will make that easier for you by standardising a load of stuff. That constraint buys a lot of power.
        globular-toast 2y ago
        Nothing is ever just pure CRUD, though. What would you say is the minimum level of business logic where one should consider Django the wrong tool for the job? One of the problems I find is gradually complexity creep from the business. It starts off as a little clean method here, a signal there etc. Before you know it you've got a domain model tightly coupled to CRUD primitives.
        robertlagrant 2y ago
        I'd say you should be able to quantify it. "a domain model tightly coupled to CRUD primitives" is not an intrinsic evil. If you were to genuinely save money or reduce risk by, say, moving off a relational database you would just need to pick that point and motivate for a rewrite. The much higher risk IMO is building a hyper-flexible application from the start knowing what you need today is a CRUD app, just in case in future you need something else. That's how you get shelfware and awkward conversations.
  - melodyogonna 2y ago
    Can confirm. Django's ORM is the main reasons I use Django. A work of art in software design.
    - blitzar 2y ago
      I am unsure why the ORM hasn't been stripped out and made into a standalone product.
      - acdha 2y ago
        That increases the support cost so I think the first question would be who’s going to use it. Django has a lot of value from integration and you wouldn’t get that as a stand-alone product, and the people who want to mix their own framework tend to pick SQLAlchemy. If there isn’t a clear community it’d be taking time away from things existing users want in the hopes of attracting other users, so you’d really want to make sure that demand was there.
      - melodyogonna 2y ago
        Wouldn't know. However, some standalone projects are attempting to replicate the same experience, check Tortoise ORM - https://github.com/tortoise/tortoise-orm https://github.com/tortoise/tortoise-orm.

mostlysimilar 2y ago

You can do that with Rails too. The difference is that Rails defaults are very good.

aerhardt 2y ago
The Rails dev says that Rails defaults are very good and so says the Django dev about the Django defaults. The Django ORM is loved by tens, maybe hundreds of thousands of Python devs globally, and while I could raise concerns about it (for example, the async experimental capabilities fucking suck, and the core dev team is extremely slow to innovate on them on the basis that that's not "the Django way"), I've never heard anyone but a Rails dev complain that it's "too verbose". People love it so much that they'll do atrocities like import it into Jupyter notebooks or simple scripts that should otherwise have no business in bringing in those type of dependencies. I should know because when I've felt creative and a bit naughty about doing those types of things I've found out - to my unmeasurable disappointment - that there were many other trailblazers before me to write gists, Medium articles, and almost everything every type of format short of an entire O'Reilly book on how to do it.
- deaddodo 2y ago
  > I've never heard anyone but a Rails dev complain that it's "too verbose". Maybe not too verbose, but there's a large population of python devs that find SQLAlchemy (+ Alembic) the much better option.
  - kshahkshah 2y ago
    That's curious to me honestly. I really prefer the ergonomics of Django's ORM compared to when I've had to use SQLAlchemy+Alembic in the past. I find alembic incredibly confusing and poorly documented. Not that documentation matters as much nowadays with AI
    - agumonkey 2y ago
      yeah, alembic feels especially "small" and obscure compared to the hyper exhaustive nature of SQLA for everything else. felt like a side project at first
    - gmassman 2y ago
      Alembic is certainly a bit of a challenge to grasp at first, especially if you want to do anything more complicated than create or alter tables. However, it does provide a great amount of flexibility if you want to implement more complex migration functionality. It allows library developers to add powerful features that would be very difficult to do with Rails/ActiveRecord or Django ORM. FWIW I maintain the flask-audit-logger package. It allows users to maintain audit logs of specific tables using postgres triggers. Being able to create custom migration operations is really an amazing feat. The alembic docs are quite dense, but the code is well organized and very readable.
  - irjustin 2y ago
    Yeah SQL Alchemy is 1000x better. Django's ORM is miserable. User.objects.filter(company__product__product_variation__var_type__in=['var1', 'var2']) vs User.where(company: { product: { product_variation: { var_type: ['var1', 'var2'] }}}) Little things like that make it so much harder to read.
    - globular-toast 2y ago
      Not to mention SQLAlchemy supports the unit of work pattern meaning you can update many objects at once. It tracks and figures out how to apply the updates all in one go. Django supports one object at a time. With SQLAlchemy it's easy to build mappers to real domain objects that are independent of the database. Most Django people treat the Django models as entities or, worse, do business logic in views etc. It's possible to implement unit of work on top of Django, but that's then another layer you have to maintain yourself (which SQLAlchemy does for you). But SQLAlchemy is harder. It's better but it's harder. Django is easier to get going with. But it bites you later (unless your app is just CRUD, in which case Django is all you need, well that and a better way to generate HTML).
- adammarples 2y ago
  Actually the dango dev is saying that the whole appeal of dango is that you can swap the defaults out easily, kind of the opposite
  - globular-toast 2y ago
    The problem with Django is not swapping out defaults. The problem is it doesn't like to sit at the edge of an application where it belongs. Django should be equivalent of any other MVC-style framework (like Qt etc), sitting right out in the "interface" layer of your software. But it just doesn't work well out there, mostly due to how tightly coupled it is with its ORM.
    - robertlagrant 2y ago
      Django isn't that, though. That would be something like Flask. Django is batteries-included for one (broad) purpose: you are going to use a relational database to make a CRUD app and we will make that easier for you by standardising a load of stuff. That constraint buys a lot of power.
      - globular-toast 2y ago
        Nothing is ever just pure CRUD, though. What would you say is the minimum level of business logic where one should consider Django the wrong tool for the job? One of the problems I find is gradually complexity creep from the business. It starts off as a little clean method here, a signal there etc. Before you know it you've got a domain model tightly coupled to CRUD primitives.
        robertlagrant 2y ago
        I'd say you should be able to quantify it. "a domain model tightly coupled to CRUD primitives" is not an intrinsic evil. If you were to genuinely save money or reduce risk by, say, moving off a relational database you would just need to pick that point and motivate for a rewrite. The much higher risk IMO is building a hyper-flexible application from the start knowing what you need today is a CRUD app, just in case in future you need something else. That's how you get shelfware and awkward conversations.
- melodyogonna 2y ago
  Can confirm. Django's ORM is the main reasons I use Django. A work of art in software design.
  - blitzar 2y ago
    I am unsure why the ORM hasn't been stripped out and made into a standalone product.
    - acdha 2y ago
      That increases the support cost so I think the first question would be who’s going to use it. Django has a lot of value from integration and you wouldn’t get that as a stand-alone product, and the people who want to mix their own framework tend to pick SQLAlchemy. If there isn’t a clear community it’d be taking time away from things existing users want in the hopes of attracting other users, so you’d really want to make sure that demand was there.
    - melodyogonna 2y ago
      Wouldn't know. However, some standalone projects are attempting to replicate the same experience, check Tortoise ORM - https://github.com/tortoise/tortoise-orm https://github.com/tortoise/tortoise-orm.