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.
Hyperflask – Full stack Flask and Htmx framework
101–110 of 160 posts
Re: Hyperflask – Full stack Flask and Htmx framework
#102Building 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?
Re: Hyperflask – Full stack Flask and Htmx framework
#103In 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 frame…
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.
Re: Hyperflask – Full stack Flask and Htmx framework
#104Earlier quoted context omitted.
> 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 appl…
> 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.
Re: Hyperflask – Full stack Flask and Htmx framework
#105Earlier quoted context omitted.
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.
Re: Hyperflask – Full stack Flask and Htmx framework
#106Building 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.
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
Re: Hyperflask – Full stack Flask and Htmx framework
#107Earlier quoted context omitted.
> 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.
Re: Hyperflask – Full stack Flask and Htmx framework
#108Why are you writing this to us? Let claude and codex know instead. They will be the ones using it.
Re: Hyperflask – Full stack Flask and Htmx framework
#109Earlier 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
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.
Re: Hyperflask – Full stack Flask and Htmx framework
#110This 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.