[HN Gopher] Hyperflask - Full stack Flask and Htmx framework
___________________________________________________________________
Hyperflask - Full stack Flask and Htmx framework
Author : emixam
Score : 258 points
Date : 2025-10-16 12:46 UTC (10 hours ago)
(HTM) web link (hyperflask.dev)
(TXT) w3m dump (hyperflask.dev)
| sgt wrote:
| 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.
| host0 wrote:
| 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"
| });
| sgt wrote:
| Seatbelt on!
| andersmurphy wrote:
| You mean like this one? https://data-star.dev/
| sgt wrote:
| Spot on! That's why I remembered it so well and I guess
| associated it with HTMX
| hokumguru wrote:
| https://nova.app/ still the best I've seen.
| CiTyBear wrote:
| 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"
| falcor84 wrote:
| But this is about html rather than API endpoints; Flask seems
| like a much more appropriate choice.
| nop_slide wrote:
| 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.
| odie5533 wrote:
| Flask is missing... pydantic, dependency injection, openapi,
| swagger, real async.
| nop_slide wrote:
| 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.
| odie5533 wrote:
| 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?
| nop_slide wrote:
| 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.
| wiseowise wrote:
| Of course you can assemble FastAPI scrim scratch, that's
| not the point. The selling point is everything
| integrated, like Django.
| Exoristos wrote:
| So nothing of importance.
| odie5533 wrote:
| What do you do for data validation?
| rapfaria wrote:
| Is FastAPI still (micro)managed by one person?
| mrits wrote:
| I've never heard micromanaged used in this positive context
| rolisz wrote:
| It's not positive
| langitbiru wrote:
| He got funding. So, I guess he can hire some people to help
| him.
|
| https://www.sequoiacap.com/article/partnering-with-
| fastapi-l...
| brokegrammer wrote:
| 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.
| graemep wrote:
| > 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.
| brokegrammer wrote:
| > 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.
| sgt wrote:
| 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.
| grim_io wrote:
| It looks really well done.
|
| I'll definitely keep an eye on it until it hopefully matures.
| mrits wrote:
| 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
| OutOfHere wrote:
| > 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?
| mrits wrote:
| There isn't any real inherit project structure. Opinionated
| frameworks often work better with multiple people involved.
| jcmontx wrote:
| After using HTMX for some time with different frameworks, I've
| come to prefer Go + Templ + HTMX. Good match between versatility
| and simplicity!
| hunvreus wrote:
| Next stack I wanna try (right now I'm on FastAPI + Jinja2 +
| HTMX).
| itsnowandnever wrote:
| 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.
| jollyllama wrote:
| > 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.
| emixam wrote:
| 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
| emixam wrote:
| 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!
| drunx wrote:
| As a big fan of python and htmx... I'm loving it!
|
| Would check it out asap!
| vb-8448 wrote:
| 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?
| emixam wrote:
| 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.
| nodesocket wrote:
| 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.
| alex_suzuki wrote:
| 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.
| :-)
| elevation wrote:
| 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!
| recursivedoubts wrote:
| yo, i'm the htmx guy
|
| this looks awesome!
| emixam wrote:
| 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.
| mikestorrent wrote:
| 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!
| rodolphoarruda wrote:
| 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.
| reality_inspctr wrote:
| excited to try out. flask <> coding agents work really well
| together.
| librasteve wrote:
| 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
| 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.
| adastra22 wrote:
| 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.
| emixam wrote:
| 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
| hunvreus wrote:
| 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
| reality_inspctr wrote:
| yeah fastapi + htmx is very effective.
| sahillavingia wrote:
| What is the largest app powered by this framework?
| ikamm wrote:
| This is a brand new framework.
| emixam wrote:
| I've built SQLify with it: https://sqlify.me
| itsnowandnever wrote:
| alright, everyone - let's send 10Tbps to SQLify to test the
| performance of emixam's new framework
| emixam wrote:
| I would be glad having some users on this project but that
| would definitely kill it !
| turtlebits wrote:
| 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.
| steinvakt2 wrote:
| I love FastHTML!
| fvdessen wrote:
| 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.
| mervz wrote:
| 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'.
| nawgz wrote:
| Surely you're not saying the frameworks famous for ui =
| f(state) actually suck at managing state...
| jaredcwhite wrote:
| kinda does, tbh.
| fmbb wrote:
| React and Vue does not solve anything users expect.
| JodieBenitez wrote:
| > 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.
| fvdessen wrote:
| > 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.
| vb-8448 wrote:
| 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.
| andersmurphy wrote:
| 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.
| b_e_n_t_o_n wrote:
| You mean I should be storing the state of a popup menu in my
| database?
| andersmurphy wrote:
| 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
| troupo wrote:
| 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.
| andersmurphy wrote:
| 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.
| rvitorper wrote:
| 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
| hedgehog wrote:
| 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?
| stuaxo wrote:
| 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.
| emixam wrote:
| There is Flask-Admin but it's more bare bone than Django Admin.
| I plan to tackle the problem in the future.
| pplante wrote:
| 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.
| emixam wrote:
| 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
| evantbyrne wrote:
| 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?
| emixam wrote:
| 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/
| awoimbee wrote:
| 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.
| mattbillenstein wrote:
| 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.
| myko wrote:
| 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.
| focom wrote:
| in the same vein i prefer https://plainframework.com/
|
| plain keep the admin dashboard and is very agent friendly
| rodolphoarruda wrote:
| 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.
| arjie wrote:
| 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.
| rvitorper wrote:
| I like it. Simple, easy, htmx and Flask, batteries-included.
| Exactly what I was looking for
___________________________________________________________________
(page generated 2025-10-16 23:00 UTC)