It's weird that clients have no idea what a page is supposed to look like until the server tells them. I mean, they could guess or cache the last layout they go

It's weird that clients have no idea what a page is supposed to look like until the server tells them. I mean, they could guess or cache the last layout they got, but it makes stuff like partial loading states a lot harder. This kinda defeats the purpose of a SPA - a SPA lets you have instant page transitions through client-side rendering, but now you can't do that without a bunch of complicated prefetching because you need the server to tell you what the next page is. > When would a client ever decide not to request a gql schema field? Which is another thing, you have to request these giant schema represantation of the UI which is bad for performance I think the first part of your sentence solves the second - if the client is always requesting the same set of fields, you can probably give the query a name and pass that to the API instead of the actual giant schema. Overall I think this sort of pattern is still valuable because shipping around fragments of HTML to update an existing document sucks, especially if multiple branches of the DOM are changing. And it won't work on mobile. Also at the end of the day, this "server driven" UI is still a lifeless JSON blob that needs to be converted into HTML through giant JS blobs on the client. It seems really convoluted to download a description of the UI, convert it to React components, and then let React convert that to HTML. The new React Server Components project is intriguing, since it lets server-side React code render updates directly to the React runtime running in the client.