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!
I made an announcement post here: https://hyperflask.dev/blog/2025/10/14/launch-annoncement/
I love to hear feedback!
this looks awesome!
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
Language
Python vs. Raku
Web framework
Flask vs. Cro
ORM
?? vs. Red
Components
both
HTML
template vs. functional
CSS
DaisyUI/Tailwind/Bootstrap vs. Pico
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
it's called "sqlalchemy core"
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.
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.
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:
class User(Base):
__tablename__ = "users"
id: Mapped[int] = mapped_column(primary_key=True)
name: Mapped[str] = mapped_column(String, nullable=False)
orders: Mapped[list["Order"]] = relationship(back_populates="user")
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))
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:
User.most_recent_order = relationship(
Order,
primaryjoin=Order.user_id == User.id,
order_by=Order.created_at.desc(),
uselist=False,
viewonly=True
)
session.query(User).options(selectinload(User.most_recent_order)).all()
If you want to do this performantly, with one final query, you end up needing an alias:
RankedOrder = aliased(Order,
select(
Order.id, ...,
func.row_number()
.over(partition_by=Order.user_id, order_by=desc(Order.created_at))
.label("rnk")
).subquery()
)
session.execute(
select(User, RankedOrder)
.join(RankedOrder, RankedOrder.user_id == User.id)
.where(RankedOrder.rnk == 1)
)
This is just one single mildly non-trivial example. All this extra boilerplate just to get performance.
Meanwhile if you use just Core:
ranked = select(
orders.c.id, ...,
func.row_number().over(
partition_by=orders.c.user_id,
order_by=desc(orders.c.created_at)
).label("rnk"),
).subquery()
query = (
select(users, ranked)
.join(ranked, ranked.c.user_id == users.c.id)
.where(ranked.c.rnk == 1)
)
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.
you don't need .c. in recent releases, you can just use the same model attributes as in orm.
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.
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
Your last sentence negates anything you claim.
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. :-)
Notable sub-projects that could be used with Django:
Would check it out asap!