Yes that's exactly what it does, and it's possible some people don't know that because they haven't had to think about that stuff at work. But I do think the ergonomics of HTMX are better. I would argue that lowers the barrier to doing exactly what you want, which will lead to less over fetching.
I recieved a "secure patient portal message" in email from my doctor. Navigating to the actual message took 5 clicks, and each click involved waiting 3 to 12 seconds for pages to load, while all sorts of react-y things happened like hydration, spinning loading icons, placeholders. This is on gigabit internet with 50 ms ping. Shipping javascript to provide snappy UI has utterly failed, please let us go back to 1 round trip to the server for each client interaction.
1. It can save a lot of repetitive boilerplate code
2. You can keep validation rules in one spot.
I've been working with some toolkits like these after years of 'backend api, frontend vue/react/angular' and it definitely can save a lot of time. It's not always the best fit, but there isn't one approach to all applications that is the best fit. Everything has tradeoffs.
The ingenuity here is exactly not needing a roundtrip for every interaction.
You request a page -> fastapi sends the client a json defining the components -> the frontend knows how to render this json into react components that run locally just like any other js framework.
I have trouble finding the FastX project you mentioned. Can you tell me its website?
The top results I get are for the Fast and Furious movie. After specifying the context ("API", "web", "framework") I get hits for remote desktop software which also has API:
