5 ms·

>...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 HTM

>...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/)
      - deleted 9y ago
        [deleted]
- chaoticsamuel 9y ago
  It's not just the initial page load though (although that's essentially similar speed). Navigate through the site, and you shave off seconds at every next click.
- dgreensp 9y ago
  Hi Rich. On my iPhone, I get a 3-second delay between when I “swipe to go back” and when the page is usable/scrollable on the Sapper HN. When I first went to the site, via the link above, the top nav links did not seem to work reliably, and it may have been the same 3-second delay, but I’m only getting now when swiping to go back — maybe because the page is being reloaded from the server? It’s still quite a delay, though.
  - rich_harris 9y ago
    Hi David! That's odd — it sounds like maybe you're interacting with the nav before the client-side app starts, though it's a little hard to tell exactly. Will try and reproduce it here — thanks
  - shoover 9y ago
    Interesting. I get behavior like that with twitter.com on the iPad. It hangs with a blank white page for a few seconds. I always wondered what kind of client script shenanigans were going with that. Using the back button embedded in the web page does not cause the same delay.
    - boubiyeah 9y ago
      I get the same behavior on my phone with their new website too. Service worker infancy bugs?
- RobertRoberts 9y ago
  Yep, the svelte version here appears faster. I'd have to inspect the network traffic to see what it's doing with the data. But I can see a definite speed advantage in this circumstance. To bad it doesn't work everywhere like this. How fast would it load if every entry had an image? Maybe then it wouldn't seem so different? (edit: this is from a desktop/Firefox)
- RobertRoberts 9y ago
  I tried this on my phone. (Android/Firefox) And I found that it's about .5 second to navigate between pages on hn.svelte.technology And about 1.5-2 seconds with the news.ycombinator.com, on average. Sometimes the straight page load was just as fast (.5 second) and sometimes it sat there while 3-5 seconds. Yes, the svelte is generally faster on my phone as well. (I am not sure I see the need for a framework for this specific feature though, it's just a js tabs sort of interface. It doesn't seem like a good argument piece for or against this framework) I did get a possible error, the pages didn't match up after a while. Is the svelte data was being cached in a way that can't refresh properly? I can't debug this as a normal user, does hitting refresh do anything to reload the site content on the svelte site? Try this, open both sites in different tabs, and navigate around on them a few times, and after awhile, the news.ycombinator will show new content, and the other one will be different. (I am guessing older content, server cache issue? I didn't compare carefully, maybe they started off different and I didn't notice)
  - rich_harris 9y ago
    Possibly a misbehaving service worker serving stale content! I can never configure those right first time.
- dsego 9y ago
  Bearing in mind that HN loads content in html tables, which are notoriously slow to render. I am not saying it makes a huge difference, but it could have an impact.
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.

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/)
    - deleted 9y ago
      [deleted]
chaoticsamuel 9y ago
It's not just the initial page load though (although that's essentially similar speed). Navigate through the site, and you shave off seconds at every next click.
dgreensp 9y ago
Hi Rich. On my iPhone, I get a 3-second delay between when I “swipe to go back” and when the page is usable/scrollable on the Sapper HN. When I first went to the site, via the link above, the top nav links did not seem to work reliably, and it may have been the same 3-second delay, but I’m only getting now when swiping to go back — maybe because the page is being reloaded from the server? It’s still quite a delay, though.
- rich_harris 9y ago
  Hi David! That's odd — it sounds like maybe you're interacting with the nav before the client-side app starts, though it's a little hard to tell exactly. Will try and reproduce it here — thanks
- shoover 9y ago
  Interesting. I get behavior like that with twitter.com on the iPad. It hangs with a blank white page for a few seconds. I always wondered what kind of client script shenanigans were going with that. Using the back button embedded in the web page does not cause the same delay.
  - boubiyeah 9y ago
    I get the same behavior on my phone with their new website too. Service worker infancy bugs?
RobertRoberts 9y ago
Yep, the svelte version here appears faster. I'd have to inspect the network traffic to see what it's doing with the data. But I can see a definite speed advantage in this circumstance. To bad it doesn't work everywhere like this. How fast would it load if every entry had an image? Maybe then it wouldn't seem so different? (edit: this is from a desktop/Firefox)
RobertRoberts 9y ago
I tried this on my phone. (Android/Firefox) And I found that it's about .5 second to navigate between pages on hn.svelte.technology And about 1.5-2 seconds with the news.ycombinator.com, on average. Sometimes the straight page load was just as fast (.5 second) and sometimes it sat there while 3-5 seconds. Yes, the svelte is generally faster on my phone as well. (I am not sure I see the need for a framework for this specific feature though, it's just a js tabs sort of interface. It doesn't seem like a good argument piece for or against this framework) I did get a possible error, the pages didn't match up after a while. Is the svelte data was being cached in a way that can't refresh properly? I can't debug this as a normal user, does hitting refresh do anything to reload the site content on the svelte site? Try this, open both sites in different tabs, and navigate around on them a few times, and after awhile, the news.ycombinator will show new content, and the other one will be different. (I am guessing older content, server cache issue? I didn't compare carefully, maybe they started off different and I didn't notice)
- rich_harris 9y ago
  Possibly a misbehaving service worker serving stale content! I can never configure those right first time.
dsego 9y ago
Bearing in mind that HN loads content in html tables, which are notoriously slow to render. I am not saying it makes a huge difference, but it could have an impact.

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.