After using HTMX for some time with different frameworks, I've come to prefer Go + Templ + HTMX. Good match between versatility and simplicity!
Hyperflask – Full stack Flask and Htmx framework
11–20 of 160 posts
Re: Hyperflask – Full stack Flask and Htmx framework
#12Re: Hyperflask – Full stack Flask and Htmx framework
#13Curious choice of backend python. Indeed Flask is a famous python framework but it seems it has been completely overshadowed by FastAPI. I would suggest "HyperFastAPI"
A lot of people moved from Flask to FastAPI because the latter is built for async workloads by default. So, people expected massive performance improvements because the word async was associated with performance.
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.
Re: Hyperflask – Full stack Flask and Htmx framework
#14> Batteries included
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.
Re: Hyperflask – Full stack Flask and Htmx framework
#15Curious choice of backend python. Indeed Flask is a famous python framework but it seems it has been completely overshadowed by FastAPI. I would suggest "HyperFastAPI"
After using both Flask and FastAPI extensively I can attest that Flask is the better technology. Flask is extremely stable and has solid organization around them via Pallets. This is a great benefit as they are keeping the ecosystem moving forward and stable. https://palletsprojects.com/ 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 al…
Flask is missing... pydantic, dependency injection, openapi, swagger, real async.
Re: Hyperflask – Full stack Flask and Htmx framework
#16> Batteries included 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 framework is composed from many extensions indeed. You can use them independently though!
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
Re: Hyperflask – Full stack Flask and Htmx framework
#17Hello, author of hyperflask here. I'm happy to finally announce this project as I've been working on it for quite some time.
I made an announcement post here: https://hyperflask.dev/blog/2025/10/14/launch-annoncement/
I love to hear feedback!
Re: Hyperflask – Full stack Flask and Htmx framework
#18Curious choice of backend python. Indeed Flask is a famous python framework but it seems it has been completely overshadowed by FastAPI. I would suggest "HyperFastAPI"
A lot of people moved from Flask to FastAPI because the latter is built for async workloads by default. So, people expected massive performance improvements because the word async was associated with performance. 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…
> In reality, people ended up having to deal with weird bugs because asynchronous Python isn't the most ergonomic
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.
Re: Hyperflask – Full stack Flask and Htmx framework
#19After using HTMX for some time with different frameworks, I've come to prefer Go + Templ + HTMX. Good match between versatility and simplicity!
Next stack I wanna try (right now I'm on FastAPI + Jinja2 + HTMX).
Re: Hyperflask – Full stack Flask and Htmx framework
#20Earlier quoted context omitted.
A lot of people moved from Flask to FastAPI because the latter is built for async workloads by default. So, people expected massive performance improvements because the word async was associated with performance. 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…
> In reality, people ended up having to deal with weird bugs because asynchronous Python isn't the most ergonomic 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 fa…
> 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.