For some reason every time project has a starfield demo, I keep looking for the speed toggle somewhere, and I also expect it to follow my mouse cursor. Maybe in the next version of the Hyperflask website!
However, the project itself looks great. I love Htmx, although I have to admit I started looking at Datastar recently.
Curious 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"
I’ve been using htmx with basic Django views for a couple years. It’s been great. I was originally concerned that the htmx was getting hard to maintain. But in my case I got to a point where I never have to look at it again.
I wouldn’t recommend htmx for a team of more than 1 person or someone that has a lot of time to focus on the frontend. It was a great balance of rapid prototyping and solid enough to not have to worry about it
I've found it quite annoying, I'm considering going the other way for my personal project from Go+Templ+HTMX -> Flask + Jinja + HTMX. Still undecided though.
I feel like Go is quite verbose and defining templates in Templ feels painful.
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.
Why sqlorm and not sqlalchemy? I've been out of the Python dev space for a long time (maybe it shows), but I thought everyone used SQLAlchemy, and I never heard off sqlorm.
I’ve been looking for something like this but backend agnostic (library rather than a framework) because we’re already about a million lines deep into a Django project. Anyway to lift this up into something that I can just mount into a Django app?
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?
It reminds me of how PHP development used to be back in the day. That's not meant as a bad thing, I always liked how simple it made the development process for the right size project.
Quart was interesting, but it didn't seem to have as much traction as FastAPI. I also seem to understand Flask is trying to integrate some of Quart's ideas.
This feels like a contradiction to what Flask (and) htmx are. There are way too many abstractions going on. Also I don't see any integration with htmx at all?
I was expecting something like what FastHTML does where htmx is essentially built in.
I have been using htmx to build a web app and came to the conclusion that it is a dead-end.
The main problem is that the state of your frontend application is in the URL. This is not flexible enough for modern UI where you might have many different zones, widgets, popups, etc. that all need their own local navigation, activation states etc. Putting all of this in a single global url is extremely hard. Designing your app so that you don't need to put it all in the global url is harder.
This problem is trivially solved by React / Vue that all provide their version of a state store that can hold the state, and make it easy as well to have elements shared or not between the tabs of your browser.
If you build your applications like phpBB forum this is not a problem, but nowadays users expect better.
In my experience with Django the admin scaffolding saves a lot of work building UI for diagnostic and customer service workflows. Projects on other frameworks that I've been involved with end up rebuilding a lot of that stuff in their own codebase, more work and often not as good of a result. There are a lot of aspects of frameworks like Hyperflask that look attractive relative to Django but foregoing the admin framework is a high price to pay. Are there some alternate patterns other people are finding successful?
I often run my projects on Supabase and then the Supabase UI becomes a backstop where I can teach my admin users to do things if they really have to.
That, or just use Airtable as a backend, if you can get away with it.
Mostly I agree with you though, I got swept up with lots of "recent tools & frameworks" projects and I really miss the Django admin. Django+HTMX has always seemed like a tempting option.
I poked around at the code and I like some of the concepts here. Introducing jinjapy as a jinja template with frontmatter allowing me to write python code is useful in some scenarios.
I got most excited about sqlorm (https://github.com/hyperflask/sqlorm). It is way too early to feel comfortable adopting this, but I really like the concepts. I use pydantic a lot, I would love to see the SQL as docstrings as a pydantic extension. I get tired of writing serializers everywhere and would prefer to have a single pydantic model to reference throughout my codebase. Primarily I use Django, but these days am using less and less of the framework batteries outside of the ORM.
At first glance, I don't understand the design choice of appending HTML templates to the python controller files. Seems like a lot of complexity just to remove a template render call. What am I missing?
Building a framework on a non-async foundation (flask) in 2025 is bizarre.
The only way to scale a flask API is to use gevent, which is just problems waiting to happen. Asyncio is just better, safer and has been adopted by the industry.
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
> 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.
As a PHP guy and Htmx enthusiast, I wonder if the same result could be achieved with a framework like Slim; having just html files making requests to the middleware via the front-controller.
I have an admin dashboard built with FastAPI and HTMX and SQLalchemy entirely LLM-based and it was pretty easy to build. Claude Code with a puppeteer MCP is able to look at what it's building, screenshot, fill entries and build an overall fairly response UI. One thing that it screws up is it sometimes renders whole pages into a partial but fortunately when given an MCP to look at the browser it fixes it all autonomously.
A fast cycle time is key when working with LLMs because they are good at adjusting to errors but bad at getting things right first time. So I like the HTMX-based stack.
A lot of people in this thread mentioning the limitations of Flask and “why not FastAPI” etc - but I’ve found Litestar to be the best alternative and it has htmx support out of the box.
I really like Jeremy Howard’s FastHTML, though it’s still a bit immature. Anyone who likes the idea of combining a FastAPI-ish (starlette) backend and htmx should check it out.
45 comments
[ 3.1 ms ] story [ 59.1 ms ] threadHowever, the project itself looks great. I love Htmx, although I have to admit I started looking at Datastar recently.
I'll definitely keep an eye on it until it hopefully matures.
I feel like Go is quite verbose and defining templates in Templ feels painful.
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.
I made an announcement post here: https://hyperflask.dev/blog/2025/10/14/launch-annoncement/
I love to hear feedback!
- 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?
[1]: https://github.com/hunvreus/devpush
It reminds me of how PHP development used to be back in the day. That's not meant as a bad thing, I always liked how simple it made the development process for the right size project.
I was expecting something like what FastHTML does where htmx is essentially built in.
The main problem is that the state of your frontend application is in the URL. This is not flexible enough for modern UI where you might have many different zones, widgets, popups, etc. that all need their own local navigation, activation states etc. Putting all of this in a single global url is extremely hard. Designing your app so that you don't need to put it all in the global url is harder.
This problem is trivially solved by React / Vue that all provide their version of a state store that can hold the state, and make it easy as well to have elements shared or not between the tabs of your browser.
If you build your applications like phpBB forum this is not a problem, but nowadays users expect better.
What exactly are you talking about, for React? What provides "a state store"?
That, or just use Airtable as a backend, if you can get away with it.
Mostly I agree with you though, I got swept up with lots of "recent tools & frameworks" projects and I really miss the Django admin. Django+HTMX has always seemed like a tempting option.
I got most excited about sqlorm (https://github.com/hyperflask/sqlorm). It is way too early to feel comfortable adopting this, but I really like the concepts. I use pydantic a lot, I would love to see the SQL as docstrings as a pydantic extension. I get tired of writing serializers everywhere and would prefer to have a single pydantic model to reference throughout my codebase. Primarily I use Django, but these days am using less and less of the framework batteries outside of the ORM.
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.
plain keep the admin dashboard and is very agent friendly
A fast cycle time is key when working with LLMs because they are good at adjusting to errors but bad at getting things right first time. So I like the HTMX-based stack.
https://litestar.dev/