Yes, sorry didn’t mean to suggest you didn’t. Comment was more to clarify to others as the simplistic “it’s faster” can cause people to misunderstand the nuance, which is important as the developer UX of async is worse than sync. I believe we should stick to sync unless there is a significant reason not to.

The trouble with all these things is what the definition of faster is. If it’s “requests per second” then yes these async frameworks are incredible on these benchmarks with their somewhat simplistic view code (I haven’t looked in detail at the one linked, but many often are only echoing back a response).

Really for the vast majority of developers the speed that matters is “time to first meaningful paint” - the time it takes to get a webpage to display on the users browser, or for an api the time until the response is ready to be passed by your front end code. Async doesn’t increase the speed at which that will happen, except in some situations with heavily paralyzable IO within a view.

It is however true that you can get more out of your hardware with async if your are handling 10s or 100s thousands requests per second. Very few of us ever get close to that though.

(Again not suggesting you don’t know this, commenting for others)

Fair enough. Indeed - "fast" for async programs does not come out of vacuum. We just don't need to wait for IO (db, other http calls, whatever) which is common in web applications. Thus it "feels faster".

Though personally when I mentally imagine web frameworks "speed" - it is requests per second as well as getting better bang for your buck out of your hardware.

Great writeup - I think we are on the same page.

what you don't understand is that FastAPI is not a web framework, so it is neither fast nor slow, it's just a patchwork of libraries on top of Starlette.

IMHO it's just nitpicking on definition of web framework. AFAIK Flask is just a library on top of Werkzeug. :)