A colleague built an internal app on flask/htmx/sqlalchemy and had excellent results but couldn't get approval to open source it. Excited to see your work!
Language
Python vs. Raku
Web framework
Flask vs. Cro
ORM
?? vs. Red
Components
both
HTML
template vs. functional
CSS
DaisyUI/Tailwind/Bootstrap vs. Pico
So, I think you have a much wider audience with a very popular set of options - for comparison HARC stack makes more "out there" choices which I hope will appeal to the small group of folks who want to try a new way to go - like the idea of functional code for HTML (think elmlang on the server side) and are a bit allergic to Tailwind denormalization.
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.
This looks awesome. I’m building an app in pure Flask using Tailwind + DaisyUI + Bootstrap Icons which looks to be the exact stack you’ve gone with. Though admittedly I am just writing raw JavaScript without a JS framework.
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 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.
> The main problem is that the state of your frontend application is in the URL.
There are plenty of ways to maintain state, including server store, sessions, localstorage, cookies, etc. Say you want the user to be able to customize the app layout: that doesn't need to be in the URL. Now say you provide a search functionality where the user can share the results: now your search criterias definitely should be in the URL.
It's not a black or white, one actually has to think about what the application must achieve.
> modern UI where you might have many different zones, widgets, popups, etc.
This is completely independent from the HTMX matter, but not all your application functionality has to fit one screen / one URL. There's a thin line between "modern" and bloat. Unfortunately this line is crossed every day.
> React / Vue that all provide their version of a state store that can hold the state
And many times they duplicate what's already available server-side.
Hypermedia can do all of that fine. You don't need to stick it all in the url. Using simple session and cookie/tab id state can be shared and or isolated between tabs. Then just do a lookup in your backend database.
Hypermedia is also way better for realtime and multiplayer.
If anything where HTMX falls short is it doesn't put enough state on the backend, if anything it's not radical enough.
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.
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 thought the same but moving to fastapi the thing I missed most from Django is the applications that make up a django project.
Having migrations, static files and templates for one aspect of a project all grouped together is so useful and I didn't realise until I didn't have it.
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.
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'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.
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.
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’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
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?
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.
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.
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.
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.
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 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.
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.
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.
This seems like such a desperate attempt to put syntax before everything else. I can't think of a worse modern combination than flask and htmx for professional production use.
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"
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.
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.
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.
emixam|4 months ago
I made an announcement post here: https://hyperflask.dev/blog/2025/10/14/launch-annoncement/
I love to hear feedback!
recursivedoubts|4 months ago
this looks awesome!
elevation|4 months ago
librasteve|4 months ago
I am sure that many will like the blend of Python and Flask - and with server side HTMX I know that components are a key aspect
plus you website doesn't hurt my eyes like FastHTML
---
here's my comparison to https://harcstack.org
So, I think you have a much wider audience with a very popular set of options - for comparison HARC stack makes more "out there" choices which I hope will appeal to the small group of folks who want to try a new way to go - like the idea of functional code for HTML (think elmlang on the server side) and are a bit allergic to Tailwind denormalization.adastra22|4 months ago
nodesocket|4 months ago
czhu12|4 months ago
drunx|4 months ago
Would check it out asap!
vb-8448|4 months ago
reality_inspctr|4 months ago
fithisux|4 months ago
fvdessen|4 months ago
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.
JodieBenitez|4 months ago
There are plenty of ways to maintain state, including server store, sessions, localstorage, cookies, etc. Say you want the user to be able to customize the app layout: that doesn't need to be in the URL. Now say you provide a search functionality where the user can share the results: now your search criterias definitely should be in the URL.
It's not a black or white, one actually has to think about what the application must achieve.
> modern UI where you might have many different zones, widgets, popups, etc.
This is completely independent from the HTMX matter, but not all your application functionality has to fit one screen / one URL. There's a thin line between "modern" and bloat. Unfortunately this line is crossed every day.
> React / Vue that all provide their version of a state store that can hold the state
And many times they duplicate what's already available server-side.
andersmurphy|4 months ago
Hypermedia is also way better for realtime and multiplayer.
If anything where HTMX falls short is it doesn't put enough state on the backend, if anything it's not radical enough.
mervz|4 months ago
And it's funny that you think anything about React and/or Vue is 'trivial'.
fmbb|4 months ago
the_gipsy|4 months ago
What exactly are you talking about, for React? What provides "a state store"?
vb-8448|4 months ago
skeezyjefferson|4 months ago
hunvreus|4 months ago
- 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
fletchowns|4 months ago
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.
rdedev|4 months ago
reality_inspctr|4 months ago
hedgehog|4 months ago
stuaxo|4 months ago
Having migrations, static files and templates for one aspect of a project all grouped together is so useful and I didn't realise until I didn't have it.
emixam|4 months ago
waterproof|4 months ago
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.
turtlebits|4 months ago
I was expecting something like what FastHTML does where htmx is essentially built in.
steinvakt2|4 months ago
jcmontx|4 months ago
callamdelaney|4 months ago
I feel like Go is quite verbose and defining templates in Templ feels painful.
hunvreus|4 months ago
sgt|4 months ago
However, the project itself looks great. I love Htmx, although I have to admit I started looking at Datastar recently.
host0|4 months 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|4 months ago
hokumguru|4 months ago
rubenvanwyk|4 months ago
https://litestar.dev/
mrits|4 months ago
OutOfHere|4 months ago
Why is this? Do larger teams have time for busywork that they can't fill with HTMX?
evantbyrne|4 months ago
emixam|4 months ago
It's inspired by Astro Pages [1] which are the same thing in the javascript world. I really liked the developer experience working with them.
[0] https://htmx.org/essays/locality-of-behaviour/ [1] https://docs.astro.build/fr/basics/astro-pages/
pplante|4 months ago
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.
emixam|4 months ago
I've also submitted SQLORM on HN if it's of interest to others: https://news.ycombinator.com/item?id=45607688
awoimbee|4 months ago
myko|4 months ago
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.
mattbillenstein|4 months ago
And most apps don't need crazy scale, they need simplicity.
procaryote|4 months ago
JSR_FDED|4 months ago
instig007|4 months ago
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.
callamdelaney|4 months ago
jollyllama|4 months ago
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.
emixam|4 months ago
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
arjie|4 months ago
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.
clickety_clack|4 months ago
v3ss0n|4 months ago
focom|4 months ago
plain keep the admin dashboard and is very agent friendly
fasteo|4 months ago
[1] https://www.xmlui.org/ [2] https://docs.flightphp.com/en/v3/
tracker1|4 months ago
https://www.jetbrains.com/guide/dotnet/tutorials/htmx-aspnet...
sahillavingia|4 months ago
emixam|4 months ago
_vqpz|4 months ago
rvitorper|4 months ago
grim_io|4 months ago
I'll definitely keep an eye on it until it hopefully matures.
rodolphoarruda|4 months ago
sublinear|4 months ago
unknown|4 months ago
[deleted]
panagathon|4 months ago
whatever1|4 months ago
andrewmcwatters|4 months ago
[deleted]
unknown|4 months ago
[deleted]
michaelyin|4 months ago
[deleted]
CiTyBear|4 months ago
brokegrammer|4 months ago
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.
nop_slide|4 months ago
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 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.
falcor84|4 months ago
rapfaria|4 months ago