3 ms·

Do you have any data to prove that server-side rendering will lead to "faster" websites? The article definitely doesn't provide any. Server-side rendering mean

Do you have any data to prove that server-side rendering will lead to "faster" websites? The article definitely doesn't provide any. Server-side rendering means the web page will be blank until the server responds. If a majority of the heavy lifting is done on the server, you increase the opportunity of slower server response times. That's a worse UX than a web page gradually loading on the client-side. Things like CSS cannot be rendered on the server, yet CSS is often a bottleneck to rendering. Same goes for images and fonts. Where's the data showing "client storage" and "client compute" are the culprits of slow websites?

kawsper 6y ago
> Server-side rendering means the web page will be blank until the server responds. With technologies such as Turbolinks and Stimulus.js it doesn't have to be that way, that's what Basecamp uses.
- jameslk 6y ago
  Turbolinks and the like just move the problem elsewhere. Great, now your site is no longer blank on subsequent loads but your first input delay has jumped by a magnitude since the server still takes forever to respond. There's still a delay regardless. Also Turbolinks only becomes useful after the page has loaded. So every fresh visitor is still going to see that horrible flash of blankness, wondering if the site is broke. That isn't to say it's worse than just default server-side rendering: I think it provides a better UX. But who knows how much, and who knows if it's better than a SPA. Nobody is citing any real data here, just talking out there ass.
bob1029 6y ago
The server has more knowledge than the client. Once economies of scale kick in, you can start to do things like speculative rendering of pages for users based upon prior access patterns, time of day, region, preferences, etc. For instance, you could have a pre-render rule that says to trip if there's an 80% chance the user is just going to proceed to checkout and not back to the store based upon the type of product in the cart. This would mean that while the user is reviewing their shopping cart & options, the server could be generating the next view. Once the client hits "Proceed to Payment", the server (or CDN) can instantly provide the cached response from memory. This basically takes UX latency down to RTT between client & server if you have a very predictable application or are willing to speculate on a large number of possibilities at once.

kawsper 6y ago

> Server-side rendering means the web page will be blank until the server responds. With technologies such as Turbolinks and Stimulus.js it doesn't have to be that way, that's what Basecamp uses.

jameslk 6y ago
Turbolinks and the like just move the problem elsewhere. Great, now your site is no longer blank on subsequent loads but your first input delay has jumped by a magnitude since the server still takes forever to respond. There's still a delay regardless. Also Turbolinks only becomes useful after the page has loaded. So every fresh visitor is still going to see that horrible flash of blankness, wondering if the site is broke. That isn't to say it's worse than just default server-side rendering: I think it provides a better UX. But who knows how much, and who knows if it's better than a SPA. Nobody is citing any real data here, just talking out there ass.

bob1029 6y ago

The server has more knowledge than the client. Once economies of scale kick in, you can start to do things like speculative rendering of pages for users based upon prior access patterns, time of day, region, preferences, etc. For instance, you could have a pre-render rule that says to trip if there's an 80% chance the user is just going to proceed to checkout and not back to the store based upon the type of product in the cart. This would mean that while the user is reviewing their shopping cart & options, the server could be generating the next view. Once the client hits "Proceed to Payment", the server (or CDN) can instantly provide the cached response from memory. This basically takes UX latency down to RTT between client & server if you have a very predictable application or are willing to speculate on a large number of possibilities at once.