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