"SimpleSSR: Don't do SSR" is as humorous as "SimpleC++: Don't use C++". I'm guessing it's funny to SSR haters? (Related question: Are "SSR haters" a thing?)
So is the essence of this particular hot-take that it's better to render pages per-request with Ruby or PHP than to serve a rendered result that has no additional per-request overhead?
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.
> 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".
"SimpleSSR: Don't do SSR" is as humorous as "SimpleC++: Don't use C++". I'm guessing it's funny to SSR haters? (Related question: Are "SSR haters" a thing?)
So is the essence of this particular hot-take that it's better to render pages per-request with Ruby or PHP than to serve a rendered result that has no additional per-request overhead?