4 ms·

I started working with Python around 2013 and I still consider Django the best framework to use. Yes Flask you can pick what you want to use but I have found t

I started working with Python around 2013 and I still consider Django the best framework to use. Yes Flask you can pick what you want to use but I have found the supporting libraries to be a bit outdated. Everytime I have used it I feel like I am just gluing together a lot of different pieces and it becomes messy. Django is constantly updated and I have little to no worries about security issues. Edit: And I have been following new projects such as starlette which I have really enjoyed but I have not bought into the idea of why I need async database access.

ensignavenger 7y ago
It's also a myth that Django makes it difficult to pick and choose. For example, this article fails to mention that Django includes support for alternative template engines, including the popular Jinja2. Of course, if you choose not to use a feature like the ORM, you won't get any of the benefits of that feature- but Django doesn't get in your way or make it difficult in any way to do so. You can use as many different ORMs (or no ORM) as you like with Django.
- guggle 7y ago
  Everything you wrote is true, however I think using another ORM in Django is asking for trouble, or at least it's missing a lot of the benefit of Django. The way models work with admin, forms, etc is to me what makes Django so efficient. Also, you don't get much by switching Django templates to Jinja.
  - nine_k 7y ago
    I did write a Django project with SQL Alchemy and without any ORM whatsoever. It made sense because it was database-heavy and UI-light. Yes, you have to do a bit more when producing forms. You have to do it anyway if your DB operations are not simple CRUD. Sure you lose much of admin stuff, too. Django is a framework, a structure where you add (preferably small) pieces of your code to customize its behavior. If what you are building deviates seriously from what the framework was intended for, it quickly becomes more of nuisance than help. But within its subject area, a framework is highly efficient.
  - miki725 7y ago
    There are efforts in improving that in 3rd party libs such as django-sorcery [1] which attempts to add Django-like ORM experience but with SQLAlchemy and django-rest-witchcraft [2] which is adding DRF integration to SQLAlchemy models. Not everything Django ORM does is supported however a lot of useful functionality works as expected. For example nested resource updates in serializers in DRF works out of the box without needing to write custom logic unlike in vanilla Django ORM DRF. Whats surprising is that the libs dont do too much magic to make it all work and most of it fairly simply plugs into Django so its not as troublesome as people might want to believe to integrate other things in Django. Its actually a pretty nice framework. Anyways for full disclosure Im a contributor to the mentioned libraries so I could be a bit biased here :D [1] https://pypi.org/project/django-sorcery/ https://pypi.org/project/django-sorcery/ [2] https://pypi.org/project/django-rest-witchcraft/ https://pypi.org/project/django-rest-witchcraft/
    - guggle 7y ago
      Thank you. Do you know of any effort to port GeoDjango functionality to other ORMs ? Or is this something Sorcery supports ?
  - scardine 7y ago
    > Also, you don't get much by switching Django templates to Jinja. Well, you gain a lot of performance - as much as 10x depending on the complexity of your template. Also, Jinja is a lot less crippled than Django Templates (for example, you can't call a function/method with parameters in Django Templates).
    - andybak 7y ago
      Bear in mind "crippled" was a deliberate design choice. Templates have a habit of taking over business logic and before you know it you've reinvented old school PHP.
      - scardine 7y ago
        It is a design decision from a time where the general belief was that template designers played in a lower league compared to "real" software developers. It is 2019 and personally I see no reason to think professional template designers will shoot themselves in the foot if we give them too much power. We are all consenting adults...
        haihaibye 7y ago
        A stated reason is: https://django-best-practices.readthedocs.io/en/latest/applications.html#models https://django-best-practices.readthedocs.io/en/latest/appli... A common pattern in MVC-style programming is to build thick/fat models and thin controllers. For Django this translates to building models with lots of small methods attached to them and views which use those methods to keep their logic as minimal as possible. There are lots of benefits to this approach. DRY: Rather than repeating the same logic in multiple views, it is defined once on the model. Testable: Breaking up logic into small methods on the model makes your code easier to unit test.
        scardine 7y ago
        Sound reasons but there is nothing preventing you to adopt this pattern with Jinja. :-) I'm glad that Jinja2 templates are now first-class citizens in Django as I care about performance and don't feel like patronizing template designers with a carefully handicapped template language.
guggle 7y ago
Thanks for pointing to Starlette, I didn't know it and it looks interesting. I completely agree with you on Django. I've had the chance to implement an e-commerce solution in Flask and another one in Django and the process has been a lot easier and faster with Django. You just can't beat having all the basic tools bundled and configured, along with one central documentation.
- aldoushuxley001 7y ago
  Just curious, what are you using as a payments solution for an e-commerce site in Django? I've yet to find a solid implementation for that, though I guess diving into Saleor and picking out parts of that implementation is the best choice?
  - guggle 7y ago
    We had to integrate the solution of our bank (see https://paiement.systempay.fr/doc/en-EN/form-payment/quick-start-guide/sitemap.html https://paiement.systempay.fr/doc/en-EN/form-payment/quick-s...), which was not very complicated since it's basically just a form, a hmac signature and a return URL.
some1else 7y ago
We have a legacy Django app at work. Coming from Rails and living in the npm eco-system for the past few years, Django to me seems like an anti-pattern framework in a death-spiral.
- deleted 7y ago
  [deleted]
- mkolodny 7y ago
  Would you mind sharing reasons why you think that?
- collyw 7y ago
  Its likely to be the application. You can write pretty nice Django or horrendously bad Django. It's MVC - essentially the same patten as Rails.
freehunter 7y ago
As with Rails, my take is that if you need to make a web app, use the big framework. The pieces you don't use don't cost much in terms of performance or maintainability, but the inverse is true otherwise: piecing together your own Django with a lighter weight framework adds a maintenance overhead that you wouldn't have with a batteries-included framework. I use Flask for simple APIs and microservices. If I'm writing a full web app, it's Rails (or Django).
- infecto 7y ago
  Thanks for pointing that out. I agree 100%. Simple APIs and microservices benefit from flask. The moment I need anything like auth though I just jump straight to Django. I don't want to think about it.

ensignavenger 7y ago

It's also a myth that Django makes it difficult to pick and choose. For example, this article fails to mention that Django includes support for alternative template engines, including the popular Jinja2. Of course, if you choose not to use a feature like the ORM, you won't get any of the benefits of that feature- but Django doesn't get in your way or make it difficult in any way to do so. You can use as many different ORMs (or no ORM) as you like with Django.

guggle 7y ago
Everything you wrote is true, however I think using another ORM in Django is asking for trouble, or at least it's missing a lot of the benefit of Django. The way models work with admin, forms, etc is to me what makes Django so efficient. Also, you don't get much by switching Django templates to Jinja.
- nine_k 7y ago
  I did write a Django project with SQL Alchemy and without any ORM whatsoever. It made sense because it was database-heavy and UI-light. Yes, you have to do a bit more when producing forms. You have to do it anyway if your DB operations are not simple CRUD. Sure you lose much of admin stuff, too. Django is a framework, a structure where you add (preferably small) pieces of your code to customize its behavior. If what you are building deviates seriously from what the framework was intended for, it quickly becomes more of nuisance than help. But within its subject area, a framework is highly efficient.
- miki725 7y ago
  There are efforts in improving that in 3rd party libs such as django-sorcery [1] which attempts to add Django-like ORM experience but with SQLAlchemy and django-rest-witchcraft [2] which is adding DRF integration to SQLAlchemy models. Not everything Django ORM does is supported however a lot of useful functionality works as expected. For example nested resource updates in serializers in DRF works out of the box without needing to write custom logic unlike in vanilla Django ORM DRF. Whats surprising is that the libs dont do too much magic to make it all work and most of it fairly simply plugs into Django so its not as troublesome as people might want to believe to integrate other things in Django. Its actually a pretty nice framework. Anyways for full disclosure Im a contributor to the mentioned libraries so I could be a bit biased here :D [1] https://pypi.org/project/django-sorcery/ https://pypi.org/project/django-sorcery/ [2] https://pypi.org/project/django-rest-witchcraft/ https://pypi.org/project/django-rest-witchcraft/
  - guggle 7y ago
    Thank you. Do you know of any effort to port GeoDjango functionality to other ORMs ? Or is this something Sorcery supports ?
- scardine 7y ago
  > Also, you don't get much by switching Django templates to Jinja. Well, you gain a lot of performance - as much as 10x depending on the complexity of your template. Also, Jinja is a lot less crippled than Django Templates (for example, you can't call a function/method with parameters in Django Templates).
  - andybak 7y ago
    Bear in mind "crippled" was a deliberate design choice. Templates have a habit of taking over business logic and before you know it you've reinvented old school PHP.
    - scardine 7y ago
      It is a design decision from a time where the general belief was that template designers played in a lower league compared to "real" software developers. It is 2019 and personally I see no reason to think professional template designers will shoot themselves in the foot if we give them too much power. We are all consenting adults...
      - haihaibye 7y ago
        A stated reason is: https://django-best-practices.readthedocs.io/en/latest/applications.html#models https://django-best-practices.readthedocs.io/en/latest/appli... A common pattern in MVC-style programming is to build thick/fat models and thin controllers. For Django this translates to building models with lots of small methods attached to them and views which use those methods to keep their logic as minimal as possible. There are lots of benefits to this approach. DRY: Rather than repeating the same logic in multiple views, it is defined once on the model. Testable: Breaking up logic into small methods on the model makes your code easier to unit test.
        scardine 7y ago
        Sound reasons but there is nothing preventing you to adopt this pattern with Jinja. :-) I'm glad that Jinja2 templates are now first-class citizens in Django as I care about performance and don't feel like patronizing template designers with a carefully handicapped template language.

guggle 7y ago

Thanks for pointing to Starlette, I didn't know it and it looks interesting. I completely agree with you on Django. I've had the chance to implement an e-commerce solution in Flask and another one in Django and the process has been a lot easier and faster with Django. You just can't beat having all the basic tools bundled and configured, along with one central documentation.

aldoushuxley001 7y ago
Just curious, what are you using as a payments solution for an e-commerce site in Django? I've yet to find a solid implementation for that, though I guess diving into Saleor and picking out parts of that implementation is the best choice?
- guggle 7y ago
  We had to integrate the solution of our bank (see https://paiement.systempay.fr/doc/en-EN/form-payment/quick-start-guide/sitemap.html https://paiement.systempay.fr/doc/en-EN/form-payment/quick-s...), which was not very complicated since it's basically just a form, a hmac signature and a return URL.

some1else 7y ago

We have a legacy Django app at work. Coming from Rails and living in the npm eco-system for the past few years, Django to me seems like an anti-pattern framework in a death-spiral.

deleted 7y ago
[deleted]
mkolodny 7y ago
Would you mind sharing reasons why you think that?
collyw 7y ago
Its likely to be the application. You can write pretty nice Django or horrendously bad Django. It's MVC - essentially the same patten as Rails.

freehunter 7y ago

As with Rails, my take is that if you need to make a web app, use the big framework. The pieces you don't use don't cost much in terms of performance or maintainability, but the inverse is true otherwise: piecing together your own Django with a lighter weight framework adds a maintenance overhead that you wouldn't have with a batteries-included framework. I use Flask for simple APIs and microservices. If I'm writing a full web app, it's Rails (or Django).

infecto 7y ago
Thanks for pointing that out. I agree 100%. Simple APIs and microservices benefit from flask. The moment I need anything like auth though I just jump straight to Django. I don't want to think about it.