7 ms·

Server-side rendering means you get a quick first load. Client-side rendering means subsequent navigations are quick, because there's less data to transfer (may

Server-side rendering means you get a quick first load. Client-side rendering means subsequent navigations are quick, because there's less data to transfer (maybe a little bit of JSON, maybe nothing at all). Going back to the server for 100kb of HTML and reloading the entire page, as opposed to fetching 10kb of JSON and instantly updating it in place, is a very 2002 way of doing things!

RobertRoberts 9y ago
>...because there's less data to transfer... The problem is that just the theory, reality if often times different. >Going back to the server for 100kb of HTML and reloading the entire page... This implies that 1) you don't go "back to the server" to load your bit of JSON. and 2) the JSON loaded doesn't require any extra templates, images or more JSON to be loaded. See the problem? It's all assumptions. Another thing, what about browser caching? I can see how the next page loads _only_ the html, as all the js, css and images were loaded already. I think you are falling for the exaggerated speed benefits from making a website with a JS framework. To be clear, I am talking about a web page, an HTML document, static content. Maybe that's where the confusion happens in discussions like this. (I said "sites", not "webapps" in my original comment) A history lesson, we did this with Flash years ago (no more page refreshes!), and everyone ultimately learned to hate it. Just because the flashy crap is spread over the entire "webapp/site" to every button, mouseover and click doesn't mean it's useful or better. (I think many devs think they need to build basic site features with big frameworks just to "stay modern".) Look at Youtube, it's slower now that they implemented their "webapp" experience, but the page doesn't "refresh", so that is somehow better... (is youtube really a webapp? Or a bunch of pages with videos on them?)
- rich_harris 9y ago
  Ultimately, the proof is in the pudding. Which is faster, when you start navigating around? * https://news.ycombinator.com/item?id=16052558 https://news.ycombinator.com/item?id=16052558 * https://hn.svelte.technology/item/16052558 https://hn.svelte.technology/item/16052558 Bear in mind that HN itself has a huge advantage over HN clones, yet — for me at least, sitting here — the Sapper version is significantly snappier.
  - Touche 9y ago
    Judging based on the 'load' event they are about the same, or the HN version might be a little bit (<100ms) faster. The Sapper version is faster with the service worker. So basically the added complexity gives you the same load time when done extremely well (as Sapper is). In terms of bang for your buck, the service worker is biggest improvement. Which you can implement in your server-rendered app.
    - rich_harris 9y ago
      What about when you start clicking the links in the nav, or opening other stories and profile pages? As far as I can see, the Sapper version blows the original out of the water.
      - lassejansen 9y ago
        The Sapper version is cheating a little. It is preloading the pages on mouseOver events of the links.
        DougWebb 9y ago
        It's not just cheating a little. Just moving the mouse around the page causes lots of data to be downloaded behind the scenes; you could end up loading every story on HN without ever leaving the Top list. That's not friendly to user's data plans, and it's very far from expected browser behavior.
        rich_harris 9y ago
        It's configurable. Add rel=prefetch to an <a> element and you'll get that behaviour; don't, and you won't. Since the links are small, mousing over them tends to suggest you intend to click them, but the exact behaviour is subject to refinement over time (this is pre-1.0 software, adjust your expectations accordingly). Incidentally, 'cheating' is a bit of a silly word to use for a feature designed to improve UX that people spend a lot of time trying to implement (see e.g. http://instantclick.io/ http://instantclick.io/)
- boubiyeah 9y ago
  I get what you mean and you are right in a way, but raw performance is not the only thing to consider. Yes, server rendered sites are usually an order of magnitude simpler to code than these JS-rendered solutions, and are often faster, but where JS rendering shines is interactivity and perceived performances: you always know what is going on! loading, sending a text, etc (provided the UX is right) Sprinkling some client-side code on top of server rendered templates is so limitating for everything but the simplest websites! It's 80% more effort for the 20% last performance/richness points. it's over, people want/expect these kinds of apps, e.g feels as good as native apps but on the web. But you're also right some people misuse that kind of technology to a ridiculous extent. Downloading a 3MB angular app just to display a crappy site without any rich interactions is really infuriating but that's just bad engineering and people who make choices based on what's popular, disregarding context.
al2o3cr 9y ago
is a very 2002 way of doing things Despite sharing a common three-letter prefix, "fast" and "fashionable" are frequently uncorrelated qualities.
timr 9y ago
Going back to the server for 100kb of HTML and reloading the entire page, as opposed to fetching 10kb of JSON and instantly updating it in place, is a very 2002 way of doing things! The difference between streaming 100kb and 10kb is small when compared to the connection latency itself. Even on a low-end LTE connection (5mbps), 100kb is 20ms, whereas the latency of a cross-country (US) transit is realistically ~50-100ms. The difference decreases further when you enable server-side compression and start doing fragment rendering, which tends to remove the penalty for HTML payloads. The argument for react-like technologies is not connection latency, but rather, the hope that you can avoid synchronous connections in the first place by moving your view logic client-side. And truthfully, few client-side apps are written in a way that would minimize payloads anyway. Most people are doing it because they hate working with the DOM and AJAX and server-side frameworks in a mishmash of web technologies, and perceive these client-side frameworks as easier.
- GordonS 9y ago
  There is also browser caching. So subsequent page loads may not require any new scripts or stylesheets to be loaded, for example, so you're only loading some GZIPped HTML.
- noxecanexx 9y ago
  You couldn't have said it any better.
goatlover 9y ago
How long does it take going back to the server and loading 100kb of HTML these days?
dsego 9y ago
If we replaced JSON with something less "chatty", would that propel us to 2022?
vitro 9y ago
You know, we may be to specialized to see that normal users that are in majority do not care. Of course you may argue that page load and responsiveness is important in regard to the conversion metrics, be it so, but imagine some average non IT person. Your mother in her seventies. A high school friend. Your auntie. Do you think they care what technology is used? Certainly not. I've seen sites that you would label ugly and from 2000's, but they just work, users can use them easily. And I have seen a rewrite of such old site to modern js framework and it was a disaster, owner was sued by users of the site as they were missing profits because the site was slow and cumbersome. I think the question is, who do you write the site for, for others or to satisfy your ego and show off?
deleted 9y ago
[deleted]

RobertRoberts 9y ago

>...because there's less data to transfer... The problem is that just the theory, reality if often times different. >Going back to the server for 100kb of HTML and reloading the entire page... This implies that 1) you don't go "back to the server" to load your bit of JSON. and 2) the JSON loaded doesn't require any extra templates, images or more JSON to be loaded. See the problem? It's all assumptions. Another thing, what about browser caching? I can see how the next page loads _only_ the html, as all the js, css and images were loaded already. I think you are falling for the exaggerated speed benefits from making a website with a JS framework. To be clear, I am talking about a web page, an HTML document, static content. Maybe that's where the confusion happens in discussions like this. (I said "sites", not "webapps" in my original comment) A history lesson, we did this with Flash years ago (no more page refreshes!), and everyone ultimately learned to hate it. Just because the flashy crap is spread over the entire "webapp/site" to every button, mouseover and click doesn't mean it's useful or better. (I think many devs think they need to build basic site features with big frameworks just to "stay modern".) Look at Youtube, it's slower now that they implemented their "webapp" experience, but the page doesn't "refresh", so that is somehow better... (is youtube really a webapp? Or a bunch of pages with videos on them?)

rich_harris 9y ago
Ultimately, the proof is in the pudding. Which is faster, when you start navigating around? * https://news.ycombinator.com/item?id=16052558 https://news.ycombinator.com/item?id=16052558 * https://hn.svelte.technology/item/16052558 https://hn.svelte.technology/item/16052558 Bear in mind that HN itself has a huge advantage over HN clones, yet — for me at least, sitting here — the Sapper version is significantly snappier.
- Touche 9y ago
  Judging based on the 'load' event they are about the same, or the HN version might be a little bit (<100ms) faster. The Sapper version is faster with the service worker. So basically the added complexity gives you the same load time when done extremely well (as Sapper is). In terms of bang for your buck, the service worker is biggest improvement. Which you can implement in your server-rendered app.
  - rich_harris 9y ago
    What about when you start clicking the links in the nav, or opening other stories and profile pages? As far as I can see, the Sapper version blows the original out of the water.
    - lassejansen 9y ago
      The Sapper version is cheating a little. It is preloading the pages on mouseOver events of the links.
      - DougWebb 9y ago
        It's not just cheating a little. Just moving the mouse around the page causes lots of data to be downloaded behind the scenes; you could end up loading every story on HN without ever leaving the Top list. That's not friendly to user's data plans, and it's very far from expected browser behavior.
        rich_harris 9y ago
        It's configurable. Add rel=prefetch to an <a> element and you'll get that behaviour; don't, and you won't. Since the links are small, mousing over them tends to suggest you intend to click them, but the exact behaviour is subject to refinement over time (this is pre-1.0 software, adjust your expectations accordingly). Incidentally, 'cheating' is a bit of a silly word to use for a feature designed to improve UX that people spend a lot of time trying to implement (see e.g. http://instantclick.io/ http://instantclick.io/)
boubiyeah 9y ago
I get what you mean and you are right in a way, but raw performance is not the only thing to consider. Yes, server rendered sites are usually an order of magnitude simpler to code than these JS-rendered solutions, and are often faster, but where JS rendering shines is interactivity and perceived performances: you always know what is going on! loading, sending a text, etc (provided the UX is right) Sprinkling some client-side code on top of server rendered templates is so limitating for everything but the simplest websites! It's 80% more effort for the 20% last performance/richness points. it's over, people want/expect these kinds of apps, e.g feels as good as native apps but on the web. But you're also right some people misuse that kind of technology to a ridiculous extent. Downloading a 3MB angular app just to display a crappy site without any rich interactions is really infuriating but that's just bad engineering and people who make choices based on what's popular, disregarding context.

al2o3cr 9y ago

is a very 2002 way of doing things Despite sharing a common three-letter prefix, "fast" and "fashionable" are frequently uncorrelated qualities.

timr 9y ago

Going back to the server for 100kb of HTML and reloading the entire page, as opposed to fetching 10kb of JSON and instantly updating it in place, is a very 2002 way of doing things! The difference between streaming 100kb and 10kb is small when compared to the connection latency itself. Even on a low-end LTE connection (5mbps), 100kb is 20ms, whereas the latency of a cross-country (US) transit is realistically ~50-100ms. The difference decreases further when you enable server-side compression and start doing fragment rendering, which tends to remove the penalty for HTML payloads. The argument for react-like technologies is not connection latency, but rather, the hope that you can avoid synchronous connections in the first place by moving your view logic client-side. And truthfully, few client-side apps are written in a way that would minimize payloads anyway. Most people are doing it because they hate working with the DOM and AJAX and server-side frameworks in a mishmash of web technologies, and perceive these client-side frameworks as easier.

GordonS 9y ago
There is also browser caching. So subsequent page loads may not require any new scripts or stylesheets to be loaded, for example, so you're only loading some GZIPped HTML.
noxecanexx 9y ago
You couldn't have said it any better.

goatlover 9y ago

How long does it take going back to the server and loading 100kb of HTML these days?

dsego 9y ago

If we replaced JSON with something less "chatty", would that propel us to 2022?

vitro 9y ago

You know, we may be to specialized to see that normal users that are in majority do not care. Of course you may argue that page load and responsiveness is important in regard to the conversion metrics, be it so, but imagine some average non IT person. Your mother in her seventies. A high school friend. Your auntie. Do you think they care what technology is used? Certainly not. I've seen sites that you would label ugly and from 2000's, but they just work, users can use them easily. And I have seen a rewrite of such old site to modern js framework and it was a disaster, owner was sued by users of the site as they were missing profits because the site was slow and cumbersome. I think the question is, who do you write the site for, for others or to satisfy your ego and show off?

deleted 9y ago

[deleted]