[jamesbrewer]

The solution you offer is exactly what server rendering is meant to stop. You should load content as fast as possible and that means rendering it on the server.

Please stop putting loading icons and spinners where your content should be.

[cbsmith]

I hear you on this, but the notion that client side is inherently a bigger download is kind of crazy, no?

Heck, if the concern is really about having lots of round trips, rather than server side rendering, you could have the server side stitch the client side components and still allow client side rendering. In fact, doing it that way makes it a heck of a lot easier to avoid reloading the entire page each time. Some kind of weird disconnect here.

[jamesbrewer]

It depends. I've worked at a company where the compressed and gzipped JavaScript file was over 1MB because there were multiple libraries being included for the use of one function.

That's obviously an extreme example.

Ultimately it's the engineer's job to make good decisions.

[cbsmith]

> That's obviously an extreme example.

No, I think that's missing the point. Sure it could be larger, but presuming you are trying to optimize the experience, there is nothing that would require doing it server side.

Why would the total payload needed to render the page client side _have to be larger_ than if it were client side? Unless you are talking about rendering an image with client side logic instead of sending a PNG/JPEG (in which case, sure, but that isn't what most people are talking about), I can't quite see it.