I think Turbolinks is a good answer. Only serve what’s changed, which on a normal website isn’t a lot. And it works without having to switch your whole stack to Javascript which is a plus.

Turblinks, and/or https://intercoolerjs.org/ with a very similar, but more generalized approach.

Anecdotally I can say this is because people either fail to implement or actively fight browser based caching techniques. I can forgive people for not taking the time to implement ETags, but it's surprisingly common practice to include headers on REST calls to disable caching.

I know that it's gauche to post links to other parts of a thread, but I didn't want you to miss this:

https://news.ycombinator.com/item?id=21933356

For me the main appeal to SPAs are testing oriented. Assuming I need some kind of interactive functionality that can't be done using a form, testing across the browser interface is difficult when doing HTML view production on the server side. If you are doing HTML view production on the client side, suddenly it's much easier. I test that the server produces the correct data given a request and I test that the client renders the correct views given the data. In Michael Feather's parlance, I've got a viable "seam" for testing against.

But if something can be done with links and forms, SPA makes it harder to test. So I prefer using JS only for islands of interactivity within specific pages, not making the whole application one big island.

I mean, yes, but from a broader perspective, didn't you create your "seam" by adding in an entire second application?

Out of couriosity, how is testing on the client easier?

I'd think you still have to verify the same way that the results are correctly rendered - except now you have to verify that the DOM is correctly generated as well.