Client vs Server Processing

I bet it saves them some server $. Probably keep more data client-side and batching to server.

How is it a good idea for every user interaction to hit the server?

That's still client side though. Seems like if they made it server-side it'd require fewer round trips.

What's the use case for this? Is doing a roundtrip to the server on every client interaction ever a good idea for building user facing UI?

Isn't that all done on the client? Soon as you require a HTTP response on potentially a slow connection it's no longer instant and a poor user experience.

This doesn't make sense. Can you elaborate? If it's not much work for the server, why would it be work for the browser?

Your site keeps most of the logic on the backend, and only makes a single roundtrip to the server per user interaction - that makes you significantly less subject to latency problems than the trendy PWAs that implement most of their logic in the frontend (and then have to issue multiple queries to the backend to load the necessary data)

Yes, in some cases when you don't need a trip to the server. But you're also bloating the client for no great benefit.

You can be even faster if you store data in client. Though different use case different solutions.

"code/framework overhead" is fine as long as its hidden in a library. Too many people re-implement a data layer client-side that is always a poor mapping to the server data model. My frontend should act as if its running off a local database and sync with the server. It could batch together all requests made to this database that it cannot fulfil or that are stale.