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.

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.

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/ [2] https://pypi.org/project/django-rest-witchcraft/

Thank you. Do you know of any effort to port GeoDjango functionality to other ORMs ? Or is this something Sorcery supports ?

> 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).

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.

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...

A stated reason is:

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.

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.

Thank you for pointing to the performance improvement, although I never found the templates to be the bottleneck (insert usual suspects here) it's good to know. Since I actually started my journey into python web development with flask+jinja2 and while I found the lack of parameters in Django templates disturbing at first, in practice it never really stopped me (custom template tags and filters...)

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.

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.

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?

We had to integrate the solution of our bank (see 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.

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).

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.

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.

Would you mind sharing reasons why you think that?

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.