But the runtime behavior will near-certainly far-prefer a thicker client model, where more is retained & locally available.
This was obvious & clear in the aughts, as web-apps emerged from purely server-side systems. 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.
It seems still likely & obviously true now. But folks sure AF love load time metrics!
> 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.
The whole point of SPAs is to run code on the client instead of servers. That tells us that the load time will favor SSR for any site where the code and/or supporting data is much larger than the displayed result. This means that the question of what’s better depends on how much data you’re talking about and whether you do enough dynamic behavior to make up for the unavoidably slower initial load time, and weather doing that dynsmic work locally is a net win relative to doing fewer requests over a higher latency / lower bandwidth network. This is different for every application so there isn’t a global optimum. Hybrid approaches (progressive enhancement, hydration) are also popular for blending the two, as are approaches like CDN edge execution, which again suggests different sweet spots for different types of applications.
The correct answer is to measure and adjust. I have seen exactly zero SPAs which delivered the authors’ original expectations for performance so I’d always rely on data.
This can also be repeated for reliability: SPAs can be great for reducing server load if you can run a lot of work on the client, but that comes at the cost of giving up control of more of the runtime environment and complicating monitoring and support. The right balance is going to depend on what you’re doing, who your users are, and where you’re running servers.
The other big factor to consider is development time. Writing an SPA requires shipping a lot more code to the client and taking on more responsibility to duplicate what browsers have built-in - for example, they usually have significant accessibility challenges which are easy to miss until late in the cycle. That extra code necessitates more work on things like packaging and since you’re running it on other people’s computers deployment is more complicated. Again, different teams will have different sweet spots based on their staffing, needs, and chosen tools.