> Is doing a roundtrip to the server on every client interaction ever a good idea for building user facing UI?

Hold on I thought HN is all hyped about HTMX now? Isn't that what that does too?

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.

It can be.

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.

It's even called "FastUI", that is hilarious.

Htmx and phoenix liveview do this, and they’re quite popular

Internal tooling