Versus FastAPI which is lead by a single maintainer which you can search back on HN about opinions on how he's led things.
Flask also has at time of writing only 5 open issues and 6 open PRs, while FastAPI has over 150 PRs open and 40 pages(!) of discussions (which I believe they converted most of their issues to discussions).
Lastly on the technical side, I found Flasks threaded model with a global request context to be really simple to reason about. I'm not totally sold on async Python anymore and encountered odd memory leaks in FastAPI when trying to use it.
https://luolingchun.github.io/flask-openapi3/v4.x/
> dependency injection
While nice I never found this to be a critical deciding factor of using a technology.
> real async
If you really want it there is Quart which is real async
https://github.com/pallets/quart
I'm not a huge async fan in python anymore so not it's not a huge issue for me. But there are definitely options for Flask if you want to use async.
https://www.sequoiacap.com/article/partnering-with-fastapi-l...
In reality, people ended up having to deal with weird bugs because asynchronous Python isn't the most ergonomic, while having negligible to zero performance improvements. Proof that most people are terrible at choosing tech stacks.
Then, AI came into the scene and people were building APIs that were essentilly front-ends to third party LLM APIs. For example, people could build an API that will contact OpenAI before returning a response. That's where FastAPI truly shined because of native asynchronous views which provides better performance over Flask's async implementation. Then people realized that can can simply access OpenAI's API instead of calling another front-end API first. But now they're already invested in FastAPI, so changing to another framework isn't going to happen.
Either way, I like FastAPI and I think Sebatian Ramirez is a great dude who knows what he wants. I have respect for a person who know how to say no. But it's unfortunate that people believe that Flask is irrelevant just because FastAPI exists.
That is an understatement. I loathe working with async Python.
> For example, people could build an API that will contact OpenAI before returning a response. That's where FastAPI truly shined because of native asynchronous views which provides better performance over Flask's async implementation.
TO be fair there are lots of other things that require a response from an API before responding to the request and therefore async reduces resource usage over threads or multi-process.
Agreed. However, these are rare and many people have been abusing asynchronous views instead of delegating the task to a background worker when multiple external requests are required. Showing a spinner while polling a synchronous view is dead simple to implement and more resilient against unexpected outages.
I'll definitely keep an eye on it until it hopefully matures.
Why is this? Do larger teams have time for busywork that they can't fill with HTMX?
Yeah, there's a lot of dependencies here - like a dozen other Flask extensions. When I saw this, I was excited about the component system, but it's too bad that it's so far from just being Flask and HTMX.
The component system is not fully independent because it depends on multiple other extensions but it mostly is as this extension: https://github.com/hyperflask/flask-super-macros
On the GitHub organization there is a list of all the extensions that are built as part of the project: https://github.com/hyperflask
I made an announcement post here: https://hyperflask.dev/blog/2025/10/14/launch-annoncement/
I love to hear feedback!
Would check it out asap!
- Components: https://hyperflask.dev/guides/components/ - Bundling view and controller in the same file: https://hyperflask.dev/guides/interactive-apps/
I think these may be footguns though. Components for example are just a regular macros under the hood. Why not use macros then?
I'm also curious about the choice of Flask. I started with a similar approach for /dev/push [1], but ended up moving to FastAPI + Jinja2 + Alpine.js + HTMX once I figured out FastAPI wasn't just for APIs. I wanted proper async support. I love Flask, but don't you find it limiting?
I was expecting something like what FastHTML does where htmx is essentially built in.
sgt•2h ago
However, the project itself looks great. I love Htmx, although I have to admit I started looking at Datastar recently.
host0•1h ago
new WarpSpeed("warpdrive", { "speed": 20, "speedAdjFactor": 0.03, "density": 2, "shape": "circle", "warpEffect": true, "warpEffectLength": 5, "depthFade": true, "starSize": 3, "backgroundColor": "hsl(224,15%,14%)", "starColor": "#FFFFFF" });
andersmurphy•1h ago