Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hyperflask – Full stack Flask and Htmx framework

hyperflask.dev

Post reply on HN
Print view View original

81–90 of 160 posts

Re: Hyperflask – Full stack Flask and Htmx framework

#81

Post by arjie »

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.

Re: Hyperflask – Full stack Flask and Htmx framework

#82

Post by andersmurphy »

b_e_n_t_o_n wrote: post #78
andersmurphy wrote: post #42

Earlier quoted context omitted.

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

Re: Hyperflask – Full stack Flask and Htmx framework

#83

Post by jaredcwhite »

nawgz wrote: post #72
mervz wrote: post #36

Earlier quoted context omitted.

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…

kinda does, tbh.

Re: Hyperflask – Full stack Flask and Htmx framework

#84

Post by troupo »

b_e_n_t_o_n wrote: post #78
andersmurphy wrote: post #42

Earlier quoted context omitted.

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?

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.

Re: Hyperflask – Full stack Flask and Htmx framework

#85

Post by andersmurphy »

troupo wrote: post #84
b_e_n_t_o_n wrote: post #78

Earlier quoted context omitted.

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.

Re: Hyperflask – Full stack Flask and Htmx framework

#86

Post by adastra22 »

emixam wrote: 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!

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.

Re: Hyperflask – Full stack Flask and Htmx framework

#87

Post by emixam »

adastra22 wrote: post #86
emixam wrote: 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!

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

Re: Hyperflask – Full stack Flask and Htmx framework

#88

Post by rvitorper »

b_e_n_t_o_n wrote: post #78
andersmurphy wrote: post #42

Earlier quoted context omitted.

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?

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

Re: Hyperflask – Full stack Flask and Htmx framework

#90

Post by fvdessen »

JodieBenitez wrote: post #38
fvdessen wrote: post #33

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…

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

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

Post reply on HN