5 ms·
I have repeated this elsewhere. APIs for UI tend to diverge from APIs in general in practice. For applications that are not highly interactive, you don't quite
by throwaway7783 1y ago
I have repeated this elsewhere. APIs for UI tend to diverge from APIs in general in practice.
For applications that are not highly interactive, you don't quite need a lot of tooling on the BE, and since need to have a BE anyway, a lot of standard tooling is already in there.
React style SPAs are useful in some cases, but most apps can live with HTMX style "SPA"s
- whatnow37373 1y agoAgreed. We started with one API to rule them all. What happened? Now we got two.. and now we have to communicate like this: “So the backend gave this weird …” “What backend?” “The backend for the frontend…” “So not the backend for the backend for the frontend?” I jest, but only very slightly.
- throwaway7783 1y agoExactly. And state is in two places now. It's like building two applications and trying to somehow keep them in sync.
- recursivedoubts 1y agohttps://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/splitting-your-apis/
- qudat 1y ago> APIs for UI tend to diverge from APIs in general in practice. I'm arguing to just use a single API, not creating one for UI, at least when you want things to be simple for multiple clients.