Live data from Hacker News

Hyperflask – Full stack Flask and Htmx framework

hyperflask.dev

111–120 of 160 posts

Re: Hyperflask – Full stack Flask and Htmx framework

#111
post #87

Earlier quoted context omitted.

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

> but I wanted something more lightweight

it's called "sqlalchemy core"

https://docs.sqlalchemy.org/en/20/core/

Re: Hyperflask – Full stack Flask and Htmx framework

#112
post #17

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!

Is this a one man effort?

Re: Hyperflask – Full stack Flask and Htmx framework

#115
post #17

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!

Is this a one man effort?

It is for now. Hoping to rally others !

Re: Hyperflask – Full stack Flask and Htmx framework

#116

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.

> 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.

Re: Hyperflask – Full stack Flask and Htmx framework

#117
post #94

Earlier quoted context omitted.

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.

not really in this case

Re: Hyperflask – Full stack Flask and Htmx framework

#118

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 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) ...

Re: Hyperflask – Full stack Flask and Htmx framework

#119
post #4

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…

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.

Re: Hyperflask – Full stack Flask and Htmx framework

#120
post #11

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.

Post reply on HN