Earlier quoted context omitted.
agreed, I'm more convinced now that django is really enough and get shit done even if there a poor support of async, more convinced after reading this blog post that async python is not faster (was on hn) : https://calpaterson.com/async-python-is-not-faster.html
It's not significantly faster (or slower), it's the author that doesn't know how to run a benchmark. You can read my take on his take [0]. Leaving that aside, async is very advisable (even a must) if your backend throws requests against external and potentially blocking services and you want to keep answering your own clients without scaling for no reason. [0] https://news.ycombinator.com/item?id=29128107
More aptly, if one can throw another physical server at it, is it worth fixing the underlying performance issue?
Sometimes the answer is yes. If you're at a place with even a thousand physical servers running your process and you can save 2% overall performance with a rewrite, that's saving you 20 physical servers worth of performance.
But often the answer is that it's not worth it. That 2% performance increase on a set of 10 servers is not calculable, and more often even a 10% performance benefit is only noticeable on some specific task, not as a constant overhead.
On the other hand, developer time is expensive and can often be best spend on core functionality.
If Django is, let's say even 20% slower than an async framework like FastAPI, but it's going to save three developers a week of development time to implement a feature in Django, then that's probably a much cheaper solution.
I've used Django, Flask, Sanic and FastAPI[1] and today I often choose FastAPI for my projects, but I think Django is still what I'd turn to if I needed to make a full fledged web application quickly, despite its performance not being as good as FastAPI.
[1] Before I learned Django, I also used Zope, and TurboGears.