It is, but that's not the comparison. The question is how well you can react to a user action if you need a network round trip in the middle. The user's already got the 2MB of JS loaded in their browser.
My stance is usually that as long as you can get a response to the user (which can be a DOM fragment, a JS snippet, whatever, doesn't matter) within 200ms, you don't need client-side rendering. And if you haven't yet got under 200ms, you shouldn't be spending time complicating your application to be distributed between the client and the server until that's fixed.
> The question is how well you can react to a user action if you need a network round trip in the middle
I do think this is the question, but the solution is not an SPA, but instant interaction feedback and no content jumping around. If you solve that, a 1-2s response from the server will seem instant, whereas with a bad implementation, you can have everything on the client-side and make that 0ms interaction look more sluggish than the one that goes to the server.
Think of a chat application, if you send a message and press send, it doesn't matter the request takes two seconds, if:
* The message is immediately shown in the chatbox
* There is direct feedback on the status of the message (sent/received/read)
* You can continue interacting with the application while the message is being sent (non-blocking)
You don't have to send all the data/messages before (server-rendered), just some logic to what happens when an action is taken.
