Many of these problems are solved: > Most bundle splitting techniques require you to load that ‘index bundle’, and then only once that JavaScript is loaded and

Many of these problems are solved: > Most bundle splitting techniques require you to load that ‘index bundle’, and then only once that JavaScript is loaded and executed does your browser know which ‘page bundle’ it needs. So you need two round-trips to start rendering. Hopefully you're performing some server-side rendering, which should know which page is being rendered, and save the browser a round-trip by including the page bundle in the initial response. > So the user will be using an old version of your JavaScript frontend with a new version of your API backend You should never couple your API backend that tightly to your frontend release version. What if you find a critical bug and have to roll back? Anyone that deals with a native app also has to deal with people not installing updates. > (regarding SSR) The first is that the page you initially render is dead You can always make your JS render-blocking if it's really that important. Most people would rather see the content first. > If you do SSR on any pages that are custom to the user, then you need to forward any cookies or authentication-relevant information to your API backend and make sure that you never cache the server-rendered result. This applies to every website. > But no option really lets a web app be careless about its data-fetching layer. This applies to every program that has to fetch data from somewhere. > Speaking of data fetching. It’s really important and really bizarre in React land This is definitely true but also something React expressly considers out of scope, for better or worse. I think the reason the GraphQL clients tend to have a better story here is that a lot of the tricky things about data fetching (data normalization, deduping queries, updating related objects, etc.) are difficult or impossible without a common query schema with standardized field types, which GraphQL provides. All in all, I think the SPA pattern has won out because it's the one pattern that lets you treat your website like an actual long-running program, instead of a series of stateless requests. People will complain about complexity and tout the zen-like purity of their Jekyll blogs, but this complexity is what allows the web, as a platform, to thrive and compete against native apps and the walled garden of app stores.