31–40 of 160 posts
I was expecting something like what FastHTML does where htmx is essentially built in.
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…
Why is this? Do larger teams have time for busywork that they can't fill with HTMX?
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.
Earlier quoted context omitted.
Flask is missing... pydantic, dependency injection, openapi, swagger, real async.
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 option…
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?
What is the largest app powered by this framework?
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…
And it's funny that you think anything about React and/or Vue is 'trivial'.
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…
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…
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.
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 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…