I was surprised to use the search feature and not see Quart mentioned: https://hyperflask.dev/guides/setup/

I've been thinking about Flask and Quart pretty much interchangeably for awhile now and use Quart for Python backends. For those who aren't aware Quart is the async Flask and they share system internals, it is usually easy to use something created for Flask for Quart.

I think you lack perspective - there is still a lot of sync code being written - I'd argue probably most deployed python is not async.

And most apps don't need crazy scale, they need simplicity.

Yep, async is not even advantage in my view - especially if it requires writing code in certain special ways.

You're not wrong, but building a new web framework is bizarre to start with, so they might as well do whatever makes them happy so it at least has had some use

I’ve had no problems with gevent at all (the opposite actually). What have you run into?

I ran into: - too high memory usage - no warning when a task doesn't yield - monkey patching: * general confusion like threading.local behaving differently * pain to integrate sentry in gunicorn with gevent since you need to import sentry after monkey patching. The OTel libs work better but you need to be careful * all compiled libs need to be replaced (eg psycogreen) ...

> Building a framework on a non-async foundation (flask) in 2025 is bizarre.

Assuming that non-blocking sockets require a special language syntax that breaks seamless compositionality of functions is a lack of fundamental knowledge. No wonder you refer to the industry adoption (crowd opinion) in your next sentence, instead of applying the first-principles analysis. In 2025, the expectation is that you should've at least tried learning how Project Loom is implemented, before venturing bold opinions on the async keyword in Python: https://openjdk.org/projects/loom/

> The only way to scale a flask API is to use gevent, which is just problems waiting to happen.

This is FUD.

In what way is FastApi better than flask?