Love your work. I wanted what it does in like 2007... always felt like extending HTML more was the way it should have gone, instead of the JS hell we spent over a decade in instead. Your work makes me feel like I'm not an idiot, and that my ideas were somewhat valid!
Thank you so much ! Great work with htmx, I'm a fan. This project is the culmination of a lot of concepts I like from many different stacks coming together.
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!
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.
sqlorm is a new orm developed as part of hyperflask.
I use sqlalchemy daily, it's an amazing library, but I wanted something more lightweight and straightforward for this project. I find the unit of work pattern cumbersome
SQLAlchemy Core isn't an ORM, it's just a very good query generator.
Although nobody seems to use the term ORM correctly any more so it's entirely possible that neither is peewee or sqlorm.
The story behind why ORM is nowadays no longer used correctly is kind of funny:
1. Query generator sounds primitive, like cavemen banging rocks together. Software engineers are scared of primitive technologies because it makes their CVs look bad.
2. Actual ORMs attempt to present a relational database as if it was a graph or document database. This fundamentally requires a translation which cannot be made performant automatically and often requires very careful work to make performant (which is a massive source of abstraction leaks in real ORMs). People don't realise the performance hit until they've written a chunk of their application and start getting users.
3. Once enough people encountered this problem, they decided to "improve" ORMs by writing new "ORMs" which "avoid" this problem by just not actually doing any of the heavy mapping. i.e. They're the re-invention of a query generator.
I don’t know if I buy that. Object-relational mapping can in principle be a broad spectrum of possibilities. SQLAlchemy (the original, not Core) is an ORM that still exposes some of the underlying relational aspects.
It is still basically a query generator, just with the helpful step of converting selected tuples into objects, and tracking changes to those objects. This means that it is often possible to solve ORM-related performance issues without too much work.
It’s been a long time since I worked with SQLAlchemy though (or even touched Python), so my memory or knowledge of the current ecosystem might be off.
Cool, the term "object-relational mapping" does indeed sound broad, as if it could be applied to merely the act of mapping tuples into something more structured, but that doesn't matter. It has a definition.
If people started using the term "data serialization" to mean taking parallel data and making it serial (for an English speaker, a perfectly reasonable meaning) would you say that this is what data serialization also was?
The term object-relational mapping refers to the very specific concept of taking relational databases and letting you access them as if they were a database of objects. Specifically, in which you had objects which held one-to-one or one-to-many or many-to-one references to other objects etc. This is a graph. The object-relational mismatch deals with the fact that relational databases and graphs are fundamentally different such that there isn't a well defined way to represent all kinds of one as the other and vice versa. Moreover, there is a performance penalty to attempting to pretend that your relational database is a graph database, and querying the relational data in ways which would make sense for a graph database.
In the case of SQLAlchemy ORM (not Core) when I worked with it back in 2018 now you could select all users from a table, or all orders. But if you wanted to select the most recent order for each user, it's much harder and requires breaking more abstractions than if you were to do it using a query generator. This is because SQLAlchemy ORM expected you to represent your data as a graph:
If you _just_ use the ORM you would write something like:
users = session.query(User).all()
most_recent_orders = []
for user in users:
if user.orders:
most_recent = max(user.orders, key=lambda o: o.created_at)
most_recent_orders.append((user, most_recent))
This is the n+1 query problem, and the performance would tank.
To avoid this, you have a few options, the simplest seems to be to add a
virtual fiend to your User object which holds the most recent order:
All this and you don't get users with their corresponding order contained within, you get an abstraction leaking sequence of tuples and their corresponding orders.
This is just one single mildly non-trivial example. All this extra boilerplate just to get performance.
I’ve written a few ORMs and you have the same performance executing a select and getting rows back and translating them into objects than you do my ORMs. It’s literally the same. Are you going to return back a Row* from your function? No. You’re going to return an object or an array. Building that from an array of rows is no different than an ORM mapping those rows for you using instructions on what field goes where.
Just like you do in your function to build an object. “Oh but it’s at compile time!” You’ll shout. So are mine. CodeGen exists. The real issue you experience is that a certain style of ORMs confuse you. Unit of work or ActiceRecord pattern style ORMs can literally be codegen’ed into your binary to make mapping as fast as new() {}.
ORMs provide you with objects and relationships. Some of them even do validation should you choose. It’s about correctness and not going Wild West on your database with no regard to schema or normalization. If you’re properly normalized, you’ll be thankful for ORMs saving you from the JOIN hell you so desperately hang on to.
You seem to be disagreeing on what the term ORM means and using the new, not very useful, and very far from the original definition. I do recommend you look at the literature of the time when ORMs and the "Object Relational Mismatch" became a hot topic and look at how ORMs worked and how people used them. Because you would be surprised to find that it's nothing like what you describe.
I didn't say you didn't want a query generator, or to have some way of mapping things automatically to native types so you are not effectively dealing with native database types.
What you don't want, which is what object relational mapping means / was designed to solve, is to force your relational data into being represented as a graph of objects when you operate on that data within your application.
To finalize:
ORMs use query generation, but they are not the originators or the only source of query generators
ORMs often provide additional validation, but they are not the originators or the only source of validation
ORMs by their definition map your SQL data to your native types, but fundamentally they do it in a way which cannot be made performant at scale. You can map things to your native types in a way which is performant but this would definitionally not be an ORM
I'm surprised an ORM is in scope for this project, but in any case I would have thought a framework would make unit of work not cumbersome. For example you could just tie the unit of work to the request cycle.
It's not heavy. The abstrations allow for consistent query compositions from reusable expressions. Demonstrate how you do conditional query building for everyone to witness the way.
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.
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‘m doing this as well, and I really like the simplicity and „no build steps“ approach.
Everything is rendered server-side, with sprinkles of modern JS where needed or useful, powered by some JSON-serving routes in the same flask app. A CSS framework on top to make it look good.
Basically more or less how we built web apps 15 years ago. :-)
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 knew of unpoly but didn't know about alpine-ajax. My choice was set on htmx since the beginning. I feel it's a more mature solution with more flexibility.
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.
> 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.
You are explaining quite well why it's hard to manage the state in a htmx app. As your app grows up all this mumbo jumbo of url, session cookies, cookies, database models becomes tangled spaghetti. You don't have to do any of this in a Vue / React app, and that reduction of complexity alone is worth the weight of those frameworks.
> You don't have to do any of this in a Vue / React app
Something has to do this in an app regardless of what UI framework you're using. Deciding where a particular piece of state lives is fundamental to web development, and yes, URL/session/cookie/database are all valid options depending what kind of state you're storing.
> You don't have to do any of this in a Vue / React app, and that reduction of complexity alone is worth the weight of those frameworks.
Well... I don't know what to say. What you call complexity is what I consider web development 101 really. And it is well worth the price: Better user experience, better performance, less code, better adherence to standards, easier app maintenance and more.
But what did I expect ? These days web developers resort to gigantic dependencies list for the most basic things.
User state is sometimes necessary, but frequently a crutch to avoid answering the real questions. Much of the time, this user-state is at the core of many performance and behavior issues as the user is burdened with unnecessary DOM reorganization. If the layout is dependent on more than just URL parameters and simple server state/cookies, then it begs the question: does this page really have a specific, well-defined purpose? If not, it's ripe for noisy UX, confused users and hard to untangle interface bugs. If so, you probably shouldn't be doing so much on-the-fly DOM configuration. You're not building an OS or window manager here.
Notably, none of this is incompatible with React/Vue where you need it.
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.
If the latency was good enough you'd store everything on the server. It doesn't force you to give them the same state when they re-open your app, you can key state by session and tabid if you want.
It's never good enough. Worse, it can abruptly become not good enough. And you have to code additional loading states or optimistic UI for every action that is now performed on the server and takes longer than some time.
> It doesn't force you to give them the same state when they re-open your app
Then why would you store modal state on the server?
It's also a consideration of resource utilization. A million clients with their own app state is better than a million clients hitting your server and requiring you to store that state.
Not if you care about state being consistent between all clients. Say you want a minimap, or a presence indicator, now the server needs to know these things. Same the minute you want backend analytics.
Millions of users hitting the same server at the same time is a very nice problem to have. I've handled 40000r/s (script kiddies are gonna script) with 500+ concurrent users in those demos on a 5$ VPS. With all the scroll position/tab state etc not just going to the server, but to a sqlite db.
Events up are fine if you batch them and 204 (i.e CQRS). In return you get a nice pushed based system that you can throttle/batch. You only push view data when the server decides to. In my case that's every 100ms (because it's a 5$ server), so all changes in that time get batched.
>Whenever your program has to interact with external entities, don't do things directly in reaction to external events. Instead, your program should run at its own pace. Not only does this make your program safer by keeping the control flow of your program under your control, it also improves performance for the same reason (you get to batch, instead of context switching on every event). Additionally, this makes it easier to maintain bounds on work done per time period.
You don't need optimistic UI, a fast server with an in process DB and a decent backend language and you'll be fine for a lot of use cases. I like to add a pop animation on the client to register something has happened, but in a lot of situations you don't even need that.
> Not if you care about state being consistent between all clients.
No idea what you mean
> Say you want a minimap, or a presence indicator, now
I struggle to see where I said that you have to have everything and anything on the client.
> Events up are fine if you batch them and 204 (i.e CQRS). In return you get a nice pushed based system that
That you have to actually code, create, and maintain.
> Whenever your program has to interact with external entities, don't do things directly in reaction to external events. Instead, your program should run at its own pace.
No idea what this has to do with anything I wrote
> You don't need optimistic UI, a fast server with an in process DB and a decent backend language and you'll be fine for a lot of use cases.
Again, this hinges on the childish belief that the network is always there, is always fast, and is always low-latency.
And none of these answer the question of why you would want to save "I showed a modal on the client" in a backend database.
This type of dismissive attitude is so strange to me. The only reason "lifecycles magic + probably global_state" would be causing your app to behave unpredictably is - this is going to shock you - because you closed your mind to a tool by dismissing it as garbage before you used it, and then failed to use it properly because you think its popularity boils down to PR.
For instance, you could entirely forgo the influence of lifecycles and global state by putting everything in a top-level Context with 1 state object that you only ever update by calling `setState`.
After that, you might find reasons to optimize your app, which could lead you to more interesting approaches like reducers or state management libraries or memoization, but I'm guessing you would never get that far and just go back to what you were doing before, since YOUR preferences are battle hardened and reliable software, while things you don't know about are only popular because of Facebook. Obviously.
I'm doing fine, thank you. Perhaps you didn't understand what I said.
My best ballpark guess for global redux usage in react projects is between 25% and at best 50% if you include redux/TEA-like libraries, but not non-pure usage.
So yes, saying that react is `ui = f(state)` does everyone a disservice. It might be true for you, but it's probably not even the average.
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.
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.
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.
I made the switch from FastAPI + Jinja + HTMX to Go and embedding the HTML into the Go binary directly... it's very nice being able to run the apps without an interpreter. I'm able to make ~5MB sized containers to run the full stack
there's a performance increase too, but these apps I'm talking about are so simple it's not enough to really notice. objectively FastAPI is really good and makes running a simple site so easy, I'd still recommend to most people using that.
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.
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 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
Isn't every project an ad hoc opinionated framework? You can do code reviews etc to get some alignment and not have everyone working against each other.
No, every project certainly isn't opinionated. There are a lot of approaches you can take to get there but I wouldn't recommend discussing alignment after the code is already written and trying to get large groups to agree.
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.
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.
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.
I ran into:
- too high memory usage
- no warning when a task doesn't yield
- monkey patching:
* general confusion like threading.local behaving differently
* pain to integrate sentry in gunicorn with gevent since you need to import sentry after monkey patching. The OTel libs work better but you need to be careful
* all compiled libs need to be replaced (eg psycogreen)
...
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 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.
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.
> 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.
> 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 agree with this. For real life stuff, Flask (or Django for that matter, my preference) is preferable over FastAPI. I used FastAPI recently for something that needed super fast (relatively speaking) async. And you just need to build a lot of stuff yourself which wastes time, comparatively speaking. If I had known, I'd probably have done it in Django and rather used Daphne or something.
Interesting. But is it also not just that Flask was build more for making websites in general, and FastAPI for making REST APIs specifically? I would say that if you want to make a REST API, that FastAPI is easier and more convenient to use.
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.
flask-openapi3 looks good but has only 246 stars. Would be worried using it in production. flask-pydantic has no openapi tie-in. Oh look, there's me bumping the openapi request that's been an issue since 2020: https://github.com/pallets-eco/flask-pydantic/issues/17 which has an open PR since 2022.
It's possible between Quart and svcs (for DI) and some Pydantic/Marshmallow/OpenAPI extension you might be able to mimic what FastAPI does. But I'd just use FastAPI. I use async too. It's a lot easier to scale in my opinion.
Do none of these pieces matter to you? Like do you not do any data validation or care about OpenAPI?
Dependency injection in fastapi honestly feels like a horrible afterthought. Flask's g is much easier to reason about, and 99% of projects don't need the 'performance improvements' of async.
Flask is old. It's mature, nothing left to add, little if anything remains to fix because nothing is really broken. OTOH its static typing story is pretty weak, and this is likely unfixable by design. Its use of one-letter global objects also feels a bit weird.
It's the "choose boring technology" poster child, of sorts: get things done reliable, without using any design younger than 15 years ago.
Hello, 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!
yo, i'm the htmx guy
this looks awesome!
Love your work. I wanted what it does in like 2007... always felt like extending HTML more was the way it should have gone, instead of the JS hell we spent over a decade in instead. Your work makes me feel like I'm not an idiot, and that my ideas were somewhat valid!
I feel you. Same here... :care:
Thank you so much ! Great work with htmx, I'm a fan. This project is the culmination of a lot of concepts I like from many different stacks coming together.
Didn't recognize you without the horse picture.
I use it in all my projects. Thank you. The Hypermedia book is incredibly good and "nostalgic" to me, a child of the web 1.0.
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!
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.
sqlorm is a new orm developed as part of hyperflask.
I use sqlalchemy daily, it's an amazing library, but I wanted something more lightweight and straightforward for this project. I find the unit of work pattern cumbersome
Considered peewee?
> but I wanted something more lightweight
it's called "sqlalchemy core"
https://docs.sqlalchemy.org/en/20/core/
SQLAlchemy Core isn't an ORM, it's just a very good query generator.
Although nobody seems to use the term ORM correctly any more so it's entirely possible that neither is peewee or sqlorm.
The story behind why ORM is nowadays no longer used correctly is kind of funny:
1. Query generator sounds primitive, like cavemen banging rocks together. Software engineers are scared of primitive technologies because it makes their CVs look bad.
2. Actual ORMs attempt to present a relational database as if it was a graph or document database. This fundamentally requires a translation which cannot be made performant automatically and often requires very careful work to make performant (which is a massive source of abstraction leaks in real ORMs). People don't realise the performance hit until they've written a chunk of their application and start getting users.
3. Once enough people encountered this problem, they decided to "improve" ORMs by writing new "ORMs" which "avoid" this problem by just not actually doing any of the heavy mapping. i.e. They're the re-invention of a query generator.
I don’t know if I buy that. Object-relational mapping can in principle be a broad spectrum of possibilities. SQLAlchemy (the original, not Core) is an ORM that still exposes some of the underlying relational aspects.
It is still basically a query generator, just with the helpful step of converting selected tuples into objects, and tracking changes to those objects. This means that it is often possible to solve ORM-related performance issues without too much work.
It’s been a long time since I worked with SQLAlchemy though (or even touched Python), so my memory or knowledge of the current ecosystem might be off.
Cool, the term "object-relational mapping" does indeed sound broad, as if it could be applied to merely the act of mapping tuples into something more structured, but that doesn't matter. It has a definition.
If people started using the term "data serialization" to mean taking parallel data and making it serial (for an English speaker, a perfectly reasonable meaning) would you say that this is what data serialization also was?
The term object-relational mapping refers to the very specific concept of taking relational databases and letting you access them as if they were a database of objects. Specifically, in which you had objects which held one-to-one or one-to-many or many-to-one references to other objects etc. This is a graph. The object-relational mismatch deals with the fact that relational databases and graphs are fundamentally different such that there isn't a well defined way to represent all kinds of one as the other and vice versa. Moreover, there is a performance penalty to attempting to pretend that your relational database is a graph database, and querying the relational data in ways which would make sense for a graph database.
In the case of SQLAlchemy ORM (not Core) when I worked with it back in 2018 now you could select all users from a table, or all orders. But if you wanted to select the most recent order for each user, it's much harder and requires breaking more abstractions than if you were to do it using a query generator. This is because SQLAlchemy ORM expected you to represent your data as a graph:
If you _just_ use the ORM you would write something like: This is the n+1 query problem, and the performance would tank.To avoid this, you have a few options, the simplest seems to be to add a virtual fiend to your User object which holds the most recent order:
But this still isn't performant, as there's going to be a double-select, one for the users, and one for the orders (filtered by the users).If you want to do this performantly, with one final query, you end up needing an alias:
All this and you don't get users with their corresponding order contained within, you get an abstraction leaking sequence of tuples and their corresponding orders.This is just one single mildly non-trivial example. All this extra boilerplate just to get performance.
Meanwhile if you use just Core:
Which looks like literally the final "ORM" code.This is what I mean when I say ORMs are either not actually ORMs or their users aren't using the ORM part for the most part.
This is complete nonsense.
I’ve written a few ORMs and you have the same performance executing a select and getting rows back and translating them into objects than you do my ORMs. It’s literally the same. Are you going to return back a Row* from your function? No. You’re going to return an object or an array. Building that from an array of rows is no different than an ORM mapping those rows for you using instructions on what field goes where.
Just like you do in your function to build an object. “Oh but it’s at compile time!” You’ll shout. So are mine. CodeGen exists. The real issue you experience is that a certain style of ORMs confuse you. Unit of work or ActiceRecord pattern style ORMs can literally be codegen’ed into your binary to make mapping as fast as new() {}.
ORMs provide you with objects and relationships. Some of them even do validation should you choose. It’s about correctness and not going Wild West on your database with no regard to schema or normalization. If you’re properly normalized, you’ll be thankful for ORMs saving you from the JOIN hell you so desperately hang on to.
You seem to be disagreeing on what the term ORM means and using the new, not very useful, and very far from the original definition. I do recommend you look at the literature of the time when ORMs and the "Object Relational Mismatch" became a hot topic and look at how ORMs worked and how people used them. Because you would be surprised to find that it's nothing like what you describe.
I didn't say you didn't want a query generator, or to have some way of mapping things automatically to native types so you are not effectively dealing with native database types.
What you don't want, which is what object relational mapping means / was designed to solve, is to force your relational data into being represented as a graph of objects when you operate on that data within your application.
To finalize:
ORMs use query generation, but they are not the originators or the only source of query generators
ORMs often provide additional validation, but they are not the originators or the only source of validation
ORMs by their definition map your SQL data to your native types, but fundamentally they do it in a way which cannot be made performant at scale. You can map things to your native types in a way which is performant but this would definitionally not be an ORM
Agree to disagree.
Your last sentence negates anything you claim.
I'm surprised an ORM is in scope for this project, but in any case I would have thought a framework would make unit of work not cumbersome. For example you could just tie the unit of work to the request cycle.
I loathe sqlalchemy
Why?
Too heavy. Too many abstractions. It always gets in my way.
It's not heavy. The abstrations allow for consistent query compositions from reusable expressions. Demonstrate how you do conditional query building for everyone to witness the way.
Intermediate data structure -> compile to SQL
how exactly do you compile to sql?
skill issue
great to see a new framework embrace HTMX ... HTMX is inspiring many new green shoots as alternatives to JS & React
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.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‘m doing this as well, and I really like the simplicity and „no build steps“ approach.
Everything is rendered server-side, with sprinkles of modern JS where needed or useful, powered by some JSON-serving routes in the same flask app. A CSS framework on top to make it look good.
Basically more or less how we built web apps 15 years ago. :-)
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?
Some of the sub-projects of hyperflask can be re-used elsewhere but most of it is Flask specific.
Notable sub-projects that could be used with Django:
- https://github.com/hyperflask/jinja-super-macros
- https://github.com/hyperflask/jinjapy
As a big fan of python and htmx... I'm loving it!
Would check it out asap!
just out of curiosity: did you consider unpoly.js or alpine-ajax instead of htmx? If yes, why did you choose htmx instead of others?
I knew of unpoly but didn't know about alpine-ajax. My choice was set on htmx since the beginning. I feel it's a more mature solution with more flexibility.
excited to try out. flask <> coding agents work really well together.
Is this a one man effort?
It is for now. Hoping to rally others !
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.
> 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.
You are explaining quite well why it's hard to manage the state in a htmx app. As your app grows up all this mumbo jumbo of url, session cookies, cookies, database models becomes tangled spaghetti. You don't have to do any of this in a Vue / React app, and that reduction of complexity alone is worth the weight of those frameworks.
> You don't have to do any of this in a Vue / React app
Something has to do this in an app regardless of what UI framework you're using. Deciding where a particular piece of state lives is fundamental to web development, and yes, URL/session/cookie/database are all valid options depending what kind of state you're storing.
> You don't have to do any of this in a Vue / React app, and that reduction of complexity alone is worth the weight of those frameworks.
Well... I don't know what to say. What you call complexity is what I consider web development 101 really. And it is well worth the price: Better user experience, better performance, less code, better adherence to standards, easier app maintenance and more.
But what did I expect ? These days web developers resort to gigantic dependencies list for the most basic things.
User state is sometimes necessary, but frequently a crutch to avoid answering the real questions. Much of the time, this user-state is at the core of many performance and behavior issues as the user is burdened with unnecessary DOM reorganization. If the layout is dependent on more than just URL parameters and simple server state/cookies, then it begs the question: does this page really have a specific, well-defined purpose? If not, it's ripe for noisy UX, confused users and hard to untangle interface bugs. If so, you probably shouldn't be doing so much on-the-fly DOM configuration. You're not building an OS or window manager here.
Notably, none of this is incompatible with React/Vue where you need it.
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.
You mean I should be storing the state of a popup menu in my database?
Correct. That's literally what happens with the scroll position, and share modal in this demo (QR code is generated on the fly on the backend):
https://checkboxes.andersmurphy.com
300ms of latency to click a checkbox is a horrible experience, though.
Feels surprisingly good to me.
not really in this case
Not sure why this is getting downvoted. I'm literally showing an example of storing popup state in the database as per the parents question.
> You mean I should be storing the state of a popup menu in my database?
No, no you shouldn't.
Well, if you want to present the user with a fully saved UI state even if the user closed your app and opens it later, then yes :)
Otherwise purely client side things should stay either fully client-side, or at most in session storage.
But what really defines client side state?
If the latency was good enough you'd store everything on the server. It doesn't force you to give them the same state when they re-open your app, you can key state by session and tabid if you want.
> But what really defines client side state?
You define it. And the client defines it.
> If the latency was good enough
It's never good enough. Worse, it can abruptly become not good enough. And you have to code additional loading states or optimistic UI for every action that is now performed on the server and takes longer than some time.
> It doesn't force you to give them the same state when they re-open your app
Then why would you store modal state on the server?
It's also a consideration of resource utilization. A million clients with their own app state is better than a million clients hitting your server and requiring you to store that state.
Not if you care about state being consistent between all clients. Say you want a minimap, or a presence indicator, now the server needs to know these things. Same the minute you want backend analytics.
Millions of users hitting the same server at the same time is a very nice problem to have. I've handled 40000r/s (script kiddies are gonna script) with 500+ concurrent users in those demos on a 5$ VPS. With all the scroll position/tab state etc not just going to the server, but to a sqlite db.
Events up are fine if you batch them and 204 (i.e CQRS). In return you get a nice pushed based system that you can throttle/batch. You only push view data when the server decides to. In my case that's every 100ms (because it's a 5$ server), so all changes in that time get batched.
>Whenever your program has to interact with external entities, don't do things directly in reaction to external events. Instead, your program should run at its own pace. Not only does this make your program safer by keeping the control flow of your program under your control, it also improves performance for the same reason (you get to batch, instead of context switching on every event). Additionally, this makes it easier to maintain bounds on work done per time period.
- tiger style https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/TI...
You don't need optimistic UI, a fast server with an in process DB and a decent backend language and you'll be fine for a lot of use cases. I like to add a pop animation on the client to register something has happened, but in a lot of situations you don't even need that.
> Not if you care about state being consistent between all clients.
No idea what you mean
> Say you want a minimap, or a presence indicator, now
I struggle to see where I said that you have to have everything and anything on the client.
> Events up are fine if you batch them and 204 (i.e CQRS). In return you get a nice pushed based system that
That you have to actually code, create, and maintain.
> Whenever your program has to interact with external entities, don't do things directly in reaction to external events. Instead, your program should run at its own pace.
No idea what this has to do with anything I wrote
> You don't need optimistic UI, a fast server with an in process DB and a decent backend language and you'll be fine for a lot of use cases.
Again, this hinges on the childish belief that the network is always there, is always fast, and is always low-latency.
And none of these answer the question of why you would want to save "I showed a modal on the client" in a backend database.
I’ve heard of a major fintech in South America that stores all the client state on the backend. Millions of users daily and it works
It's a dead end for your use case, let's be very clear about that.
And it's funny that you think anything about React and/or Vue is 'trivial'.
Surely you’re not saying the frameworks famous for ui = f(state) actually suck at managing state…
If it only were true. React is nothing like ui = f(state). More like ui = f(some_trivial_state) + lifecycles magic + probably global_state.
Garbage. But effective devrel.
This type of dismissive attitude is so strange to me. The only reason "lifecycles magic + probably global_state" would be causing your app to behave unpredictably is - this is going to shock you - because you closed your mind to a tool by dismissing it as garbage before you used it, and then failed to use it properly because you think its popularity boils down to PR.
For instance, you could entirely forgo the influence of lifecycles and global state by putting everything in a top-level Context with 1 state object that you only ever update by calling `setState`.
After that, you might find reasons to optimize your app, which could lead you to more interesting approaches like reducers or state management libraries or memoization, but I'm guessing you would never get that far and just go back to what you were doing before, since YOUR preferences are battle hardened and reliable software, while things you don't know about are only popular because of Facebook. Obviously.
So, redux? It's either redux or, sorry, "lifecycles magic + probably global_state". And who uses redux in 2025?
Honestly, if you’re getting thru life with this attitude, good for you, but you might want to consider if it’s the only way
I'm doing fine, thank you. Perhaps you didn't understand what I said.
My best ballpark guess for global redux usage in react projects is between 25% and at best 50% if you include redux/TEA-like libraries, but not non-pure usage.
So yes, saying that react is `ui = f(state)` does everyone a disservice. It might be true for you, but it's probably not even the average.
kinda does, tbh.
React and Vue does not solve anything users expect.
> This problem is trivially solved by React / Vue that all provide their version of a state store that can hold the state
What exactly are you talking about, for React? What provides "a state store"?
have you tried a native language with a networking and gui library to achieve the same thing?
maybe for very complex use cases, but I'm using htmx(and unpoly) + alpinejs + localstorage and still didn't find a case that doesn't fit.
Some interesting concepts:
- 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
> Bundling view and controller in the same file
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 moved to Quart instead. It's flask with async support built by the same developer.
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.
yeah fastapi + htmx is very effective.
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.
There is Flask-Admin but it's more bare bone than Django Admin. I plan to tackle the problem in the future.
After using HTMX for some time with different frameworks, I've come to prefer Go + Templ + HTMX. Good match between versatility and simplicity!
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.
Next stack I wanna try (right now I'm on FastAPI + Jinja2 + HTMX).
I made the switch from FastAPI + Jinja + HTMX to Go and embedding the HTML into the Go binary directly... it's very nice being able to run the apps without an interpreter. I'm able to make ~5MB sized containers to run the full stack
there's a performance increase too, but these apps I'm talking about are so simple it's not enough to really notice. objectively FastAPI is really good and makes running a simple site so easy, I'd still recommend to most people using that.
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.
Run in console:
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" });
Seatbelt on!
You mean like this one? https://data-star.dev/
Spot on! That's why I remembered it so well and I guess associated it with HTMX
https://nova.app/ still the best I've seen.
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 love FastHTML!
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 wouldn’t recommend htmx for a team of more than 1 person
Why is this? Do larger teams have time for busywork that they can't fill with HTMX?
There isn't any real inherit project structure. Opinionated frameworks often work better with multiple people involved.
Isn't every project an ad hoc opinionated framework? You can do code reviews etc to get some alignment and not have everyone working against each other.
No, every project certainly isn't opinionated. There are a lot of approaches you can take to get there but I wouldn't recommend discussing alignment after the code is already written and trying to get large groups to agree.
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.
https://litestar.dev/
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?
It's in sync with the Locality of Behavior [0] principle that htmx follows.
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/
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 was surprised to use the search feature and not see Quart mentioned: https://hyperflask.dev/guides/setup/
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.
I think you lack perspective - there is still a lot of sync code being written - I'd argue probably most deployed python is not async.
And most apps don't need crazy scale, they need simplicity.
Yep, async is not even advantage in my view - especially if it requires writing code in certain special ways.
I’ve had no problems with gevent at all (the opposite actually). What have you run into?
I ran into: - too high memory usage - no warning when a task doesn't yield - monkey patching: * general confusion like threading.local behaving differently * pain to integrate sentry in gunicorn with gevent since you need to import sentry after monkey patching. The OTel libs work better but you need to be careful * all compiled libs need to be replaced (eg psycogreen) ...
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
In what way is FastApi better than flask?
> 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.
This is FUD.
> 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
This looks unreal!
Jetbrains has released support for similar work in C# (ASP.Net). In case anyone is interested in similar tooling.
https://www.jetbrains.com/guide/dotnet/tutorials/htmx-aspnet...
Slighthy offtopic, but I have been using xmlui[1] (paired with Flight PHP framework [2]) lately for some internal tools and it has worked really well.
[1] https://www.xmlui.org/ [2] https://docs.flightphp.com/en/v3/
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.
Thanks ! I've introduced a lot of stuff with this project and I'm glad someone noticed :D
I've also submitted SQLORM on HN if it's of interest to others: https://news.ycombinator.com/item?id=45607688
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.
What is the largest app powered by this framework?
I've built SQLify with it: https://sqlify.me
alright, everyone - let's send 10Tbps to SQLify to test the performance of emixam's new framework
I would be glad having some users on this project but that would definitely kill it !
haha no worries, it's a great site, though! congrats!
Lovely!
This is a brand new framework.
Check Litestart if you want a Fullstack Async Experience for HTMX. https://litestar.dev/
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.
in the same vein i prefer https://plainframework.com/
plain keep the admin dashboard and is very agent friendly
It looks really well done.
I'll definitely keep an eye on it until it hopefully matures.
I like it. Simple, easy, htmx and Flask, batteries-included. Exactly what I was looking for
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.
Why are you writing this to us? Let claude and codex know instead. They will be the ones using it.
[dead]
[dead]
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.
> 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.
> 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.
[dead]
I agree with this. For real life stuff, Flask (or Django for that matter, my preference) is preferable over FastAPI. I used FastAPI recently for something that needed super fast (relatively speaking) async. And you just need to build a lot of stuff yourself which wastes time, comparatively speaking. If I had known, I'd probably have done it in Django and rather used Daphne or something.
Interesting. But is it also not just that Flask was build more for making websites in general, and FastAPI for making REST APIs specifically? I would say that if you want to make a REST API, that FastAPI is easier and more convenient to use.
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 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.
Flask is missing... pydantic, dependency injection, openapi, swagger, real async.
https://github.com/pallets-eco/flask-pydantic
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.
flask-openapi3 looks good but has only 246 stars. Would be worried using it in production. flask-pydantic has no openapi tie-in. Oh look, there's me bumping the openapi request that's been an issue since 2020: https://github.com/pallets-eco/flask-pydantic/issues/17 which has an open PR since 2022.
It's possible between Quart and svcs (for DI) and some Pydantic/Marshmallow/OpenAPI extension you might be able to mimic what FastAPI does. But I'd just use FastAPI. I use async too. It's a lot easier to scale in my opinion.
Do none of these pieces matter to you? Like do you not do any data validation or care about OpenAPI?
At $JOB we're using both flask-pydantic and flask-openapi via those libraries and they are serving us just fine.
But yes async does not matter to me.
Of course you can assemble FastAPI scrim scratch, that’s not the point. The selling point is everything integrated, like Django.
Dependency injection in fastapi honestly feels like a horrible afterthought. Flask's g is much easier to reason about, and 99% of projects don't need the 'performance improvements' of async.
So nothing of importance.
What do you do for data validation?
Flask is old. It's mature, nothing left to add, little if anything remains to fix because nothing is really broken. OTOH its static typing story is pretty weak, and this is likely unfixable by design. Its use of one-letter global objects also feels a bit weird.
It's the "choose boring technology" poster child, of sorts: get things done reliable, without using any design younger than 15 years ago.
But this is about html rather than API endpoints; Flask seems like a much more appropriate choice.
Is FastAPI still (micro)managed by one person?
I’ve never heard micromanaged used in this positive context
It's not positive
He got funding. So, I guess he can hire some people to help him.
https://www.sequoiacap.com/article/partnering-with-fastapi-l...