This is why you have to measure what your users actually experience and understand how they want to use your app. If you do, you learn that browser caching does not have the dramatic impact thick client proponents often assume and connections are similarly slower and less reliable. That produces unsatisfying experiences which are more memorable than the times where your app loads quickly.

> Having a client that could re-render based on dynamic data was vastly better than trying to find portals of HTML to re-render & send.

This can be true but again measurements will show it isn’t true far more than claimed in the SPA marketing materials. This is due to the reasons I mentioned in my original comment: if your SPA has to make a number of network calls to update the view with a modest amount of visible data, it’s probably going to lose compared to the same code running on a faster processor in a data center with a network path to the data which has greater bandwidth and 1-2 orders of magnitude lower latency.

The break-even point is going to depend on the type of application you have, how much data you need to touch, how well that can be cached locally or on a CDN, and where you run servers and their performance characteristics, and the usage patterns of your users.

This is why the hybrid approaches end up being most commonly successful: if you’re dogmatic about using one approach exclusively you’ll miss out on the optimizations which make sense for your users by trying to follow an approach designed for someone else in a different business.