4 ms·
It's not that simple. (I say this as a JS dev who develops SPAs for a living). For one, "no additional per-request overhead" is an oversimplification, that is
by allover 8y ago
It's not that simple. (I say this as a JS dev who develops SPAs for a living).
For one, "no additional per-request overhead" is an oversimplification, that is not the case for most SPAs that grow beyond 'small' size, see 'code-splitting'.
Modern SSR involves re-using the same client-side rendering code on the backend (which typically means a Node backend), and modern SPAs may employ some techniques to code-split the client side app, either by-route or other means.
You can make a decent case that for a lot of 'sites' this whole setup is more complex than the server-side rendered frameworks of old mentioned by this site.
- CharlesW 8y ago> For one, "no additional per-request overhead" is an oversimplification… That's fair, but setting aside packaging decisions like code-splitting (which aren't unique to SPAs), my point is that SSR is typically used to deliver content and app logic that would otherwise require round-trips to code running on a server. It hardly seems like a huge win for "SimpleSSR".