4 ms·

> "Server rendered pages are not optional" I don't get this, in my opinion they are optional, you can show the ios png placeholder (shown in the next item) whi

by jfroma 12y ago

> "Server rendered pages are not optional" I don't get this, in my opinion they are optional, you can show the ios png placeholder (shown in the next item) which is a very static and cacheable content, while fetching your highly dynamic data from a database or somewhere else. It feels like the first principle contradicts 2, 3 and 4.

jamesbrewer 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      > 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.

by jfroma 12y ago

jamesbrewer 12y ago

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 12y ago
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 12y ago
  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 12y ago
    > 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.