Some of these stated issues aren't universal. There are frameworks that pair a server side rendered page with a switchover to SPA. Providing the user with a p

Some of these stated issues aren't universal. There are frameworks that pair a server side rendered page with a switchover to SPA. Providing the user with a pre-rendered page with a follow on JS bundle that loads the SPA and the switch is seamless. It's a bit of extra work so I don't always use it, but it exists. This also removes the incompatibilities with non-browser tooling/bots/etc. (Example: quasar.dev) 2G is being phased out (at least where I live), it no longer works here. Chromium browsers have a slow-3g network effect to test your code/sites. I use it frequently. Sometimes it reveals problems, other times it's a shrug. Some features just require bandwidth and there is no reasonable way to avoid it. I do try to reduce page weight as much as I reasonably can. Lots of features of the modern browser will leak finger-printable information. The JS engine is hardly the only problem piece. I guess your general complaint here is to indicate the world is insane. I tend to agree, but I don't think this is the principle reason why :) Screen readers are notoriously difficult to make work correctly. In my experience, this is a universal issue with the web generally and isn't unique to SPAs. If we're serious about audio accessibility we need an actual standard instead of this guesswork. Breaking navigation is a pet peeve of mine too, poorly behaved front-end routers are terrible. I always target working urls into any part of the app as refreshing the page is a common operation. And I must have a properly functioning back/forward for my own sanity in development if nothing else. I will beg to differ on the point of failure. SPAs can also be apps, paired with a service worker and a local data set they can continue to function even if you are completely offline, or the server is completely offline. Obviously if your web app is just broken, yeah, nothing's going to work. But in the case of SSR, that's also true if your network is down (locally or remotely), or the server is down/broken. A well built offline-first SPA will reduce the total number of single point failures that kill all functionality. Also, offline-first SPAs have the side effect of masking some of the latency over a slow 3G link - which can improve the user experience significantly.