13 ms·

Because it's faster. If you don't have to download all the content again, force the browser to re-render everything, then by design you just get the new content

Because it's faster. If you don't have to download all the content again, force the browser to re-render everything, then by design you just get the new content from the server faster, if you have to download anything at all. The idea exists since the introduction of AJAX. Furthermore, you don't lose state, which makes things much more simple. Imagine a simple image gallery. You just update the <img> tag, update the URL with the history API and everybody is happy. If you were to navigate via links, you get the same behavior. Of course shitty implementations exists and you only notice the bad ones. If done right, you don't notice that it's happening at all. Lastly but most importantly, context matters! It's not a silver bullet, but it can be really useful.

moron4hire 7y ago
It's probably not the network round trip or the actionable content making reloading the site so slow. It's almost certainly tracking scripts, unoptimized database queries, and unoptimized assets.
- tiborsaas 7y ago
  Sure, web performance is an afterthought at many places and the more people work on a certain project the worse it gets because each team has its own motivation, but they all have the same target to shoot at. I think there's a connection between the organizational structure and the bad frontend experiences and this is almost always overlooked in these discussions. This is no surprise of course, we only see the crappy end result and blame the technologies, but this is superficial. It's usually not the certain technology that's problematic (SPA, history api, react, angular, webassebmly...) but the use of them without understanding the problem first. That's why I find it funny when I constantly read general comments here like "SPA-s are the worst".
  - ryacko 7y ago
    CSS doesn’t require javascript, and allows for nearly all the features of a SPA.
    - kowdermeister 7y ago
      Like plotting an equation to canvas? Editing video? Handling drag and drop events? I've seen that blog post where a guy demonstrated that many UI elements can be done with CSS, I like that. I try to do that myself as much as I can, but let's not pretend that CSS is a programming language and it can replace ANY JavaScript.
      - ryacko 7y ago
        It is debatable that CSS is or isn’t Turing complete, but as long as the task isn’t totally automated without user input, CSS could replace most Javascript.
  - moron4hire 7y ago
    Yes, but equally so, replying to this email comments with "but page loads are slow" is not helpful.
  - yc12340 7y ago
    SPAs are the worst, because companies deploy them to avoid separation of responsibilities and turn every employee into easily replaceable "full-stack developer". Unfortunately, a lot of people write terrible applications regardless of chosen technology. When this happens to purely server-side applications, the company is forced to optimize them to keep the hosting bill low — a positive feedback loop in action. SPA applications cause the opposite — companies move everything to client-side in order to reduce Amazon bills, and don't care if those client-side scripts are poorly optimized and contribute to global warming by causing hundred thousands machines to spin up their CPU fans. Clearly, there should be a heavy tax on single page apps. They are 1) addictive — by making more Javascript devs, who in turn write more Javascript websites 2) act as luxurious goods ("Look guys — we have created a new version of our website. It looks so cooool (but loads a bit slow)!") 3) have ugly externalities, completely ignored by most of their creators
    - kowdermeister 7y ago
      > companies deploy them to avoid separation of responsibilities and turn every employee into easily replaceable "full-stack developer" SPA-s are much-much harder to develop if more teams are working on it. So your first sentence makes little sense. > companies move everything to client-side in order to reduce Amazon bills This is never the reason why it happens. Seriously? The cost are not saved, just moved around. SPA-s are developed because they could provide a much better UX. As a side benefit, server side development becomes simpler by providing some REST or GraphQL API. You don't want to be in a place where tens of thousands of lines are generated backend side by backend developers. > client-side scripts are poorly optimized and contribute to global warming by causing hundred thousands machines to spin up their CPU fans. I appreciate your sense of humor :D
hombre_fatal 7y ago
A media gallery website is a good example of a use-case for client-side routing. I worked on a porn site that was basically an endless-scroll video gallery. Clicking a thumbnail opened the video in a modal overlay. All pages on the site were modal on top of the gallery in the background. You could deep link to a page and the gallery would load in behind it. It worked really well and had great UX. This generalizes to any website that has some sort of overall state between page transitions, like soundcloud.com playing a track as you click around.
- testis321 7y ago
  > I worked on a porn site that was basically an endless-scroll video gallery. So, if you're a horny teenager, you scrool down for a huge amount of time to find "the video" that will get you off... and you hear your mom coming up the stairs, Control+w (close tab), and when she goes downstairs again, you press Control+shift+t (reopen last closed tab), you're back at the beginning, and have to search for that video again? That sucks. Endless scrolling sucks. You go down and down and down, and something breaks (eg. bad wifi), and you lose your position, since refresh takes you back to top.
  - frereubu 7y ago
    I hate infinite scroll with a passion. I've often been quite a way down someone's interesting Twitter feed and lost my place somehow, then just given up and gone somewhere else in frustration rather than trying to scroll down a few hundred tweets, waiting each however-many tweets for the next batch to load, just to get back to where I was.
    - TeMPOraL 7y ago
      Also the slowdown. Didn't matter whether I had 8, 12 or (currently) 32 GB of RAM; couple minutes scrolling down a Twitter or Facebook feed and the whole page slows down so noticeably that I simply give up. Also: something breaks, you press F5, and now the feed is gone, or is in a completely different place than it was before refresh. Infinite scroll should be labeled as dark pattern. Its only benefit is to the companies exploiting intermittent rewards; for users, it's just bad ergonomics and bad experience.
bloaf 7y ago
Do you have an example of a site which does it well?
- kowdermeister 7y ago
  There are many good ones, but after a quick bookmark search, this shop is done really well, imho: https://www.shopflamingo.com/ https://www.shopflamingo.com/
  - thekingshorses 7y ago
    This is what makes it worse. If you scroll down on the page, and click on the link, it takes you to a new page. Works great. If you use browser back button, it takes you to the previous page, but scroll position is lost.
- mceachen 7y ago
  You can try PhotoStructure (disclaimer, I'm the author). It's an image gallery built with Vue and vue-router (for your images). If you look at the vue-router documentation, they've got some examples to follow. The back/forward buttons, command-click, and ctrl-shift-t work on all modern desktop and mobile browsers. I started with traditional page loads, but even with minimal css and no js, screen flashing between pages was prominent (especially on mobile), and visual transitions between pages (like swipe navigation where both prior and next page content is concurrently visible) is difficult.
- M4v3R 7y ago
  The blog of Svelte, the framework/compiler that was featured on HN some time ago works really well in my opinion: https://svelte.dev/blog https://svelte.dev/blog
  - bloaf 7y ago
    I don't know if their javascript is to blame, but I got this when I tried to use the back button: https://imgur.com/a/YcRtDFj https://imgur.com/a/YcRtDFj
JulianMorrison 7y ago
The idea exists but it's clearly not true, except perhaps in specific, niche uses like re-rendering a continuously refreshed graph. Even for your image gallery, it makes for confusion. Back button does what? Shift-refresh does what? Just let the browser do what it does. If you want the images to render fast, use HTML 2. Writing a web app with server side pages forces you to think about where the state lives. This is a beneficial discipline.
- kowdermeister 7y ago
  The back button would do the same as it would do after you click a [next image] link :) Not sure about your point, the history API improves UX if you do it right: https://developer.mozilla.org/en-US/docs/Web/API/History_API https://developer.mozilla.org/en-US/docs/Web/API/History_API It does everything as hand written, pure HTML page would, just do it faster.
- trop 7y ago
  Google Maps would be the classic example of client-side refresh working so well that it's now the universal choice. At the time, it was a revelation, as the Mapquest-ish predecessors (if I recall) required a click and server-side refresh to scroll or zoom the map. Of course the revelation here was that <a> tags weren't what we needed to move a map, but rather a click-and-drag plus scroll-wheel behavior to explore a huge image at various levels of detail. If the server-side page-by-page navigation paradigm is a lousy fit for information delivered over the internet, then it may make sense to re-invent the page load. To use the language of a sibling comment, this brought things to a much more app-ish behavior. And eventually Internet maps have become, especially on mobile devices, an app. Hence the need to break server-side navigation may have foreshadowed the need to break out of the browser.
  - JulianMorrison 7y ago
    I think this can be generalized as: if you need to break out of "click and wait a moment and see a changed screen" paradigm, for something like a continuously scrolling map or a smoothly flowing server load graph, then you can make good use of client-side loading. If you are just trying to re-create it, don't.
frereubu 7y ago
"You don't have to download all the content again" is also true if you version your assets and use a CDN with far-future expiry headers. If you need an HTTP connection to download a section of HTML for a new part of an SPA it won't be that much different from a full page of HTML, presuming you compress the transfer as you should. "Of course shitty implementations exist" is true of a non-SPA setup too.
- daxterspeed 7y ago
  While it's true that the browser won't have to download the content again, it will have to re-instantiate various resources (eg execute all JavaScript over again..., restart gifs). If implemented correctly, JavaScript navigation should seamlessly appear like normal navigation. Not supporting streamed requests is a serious drawback. Of course browsers have actually gotten pretty good at AJAX-like loading instead of completely re-rendering the page. These systems tend to rely on heuristics though, and I don't think there's any documentation for these, but even when these fail the browser tend to be more competent than even the best JavaScript solutions.
  - frereubu 7y ago
    I think there are good use-cases for SPAs (Google Maps, for example), but the majority of cases that I've seen aren't good ones, and the extra complexity involved in managing state etc. far outweighs any marginal gains in not re-instantiating JS.
  - zonidjan 7y ago
    > While it's true that the browser won't have to download the content again, it will have to re-instantiate various resources (eg execute all JavaScript over again..., restart gifs). Your JavaScript shouldn't be blocking page load anyway. Defer, defer, defer.
  - manigandham 7y ago
    JS is cached in its compiled state in modern browsers. There is no download or parsing step for repeated loads.
mintplant 7y ago
All major browsers cache the relevant assets (images, CSS, JS) in-memory between navigations in the same frame/tab and origin (at least).
guggle 7y ago
> Furthermore, you don't lose state, which makes things much more simple. Or not... I think about infinite scrolls with no proper paging.
- m-p-3 7y ago
  New Reddit.. shakes fist
TeMPOraL 7y ago
> Because it's faster. The whole point of the article is that it's not true. It's not the only article that disproves it, and honestly, it's not difficult to notice it. Just go to any blog running off a static site generator; loading times of pure HTML webpages on good connection are so fast they whole thing outruns client-side page switches even if the page is already in memory.
- StavrosK 7y ago
  Case in point, navigation on my site is pretty fast (to me, at least) and doesn't use much JS at all: https://www.stavros.io https://www.stavros.io (I promise I'll reply to your email soon)
  - jspash 7y ago
    I'll admit it is pretty fast. Assuming you are using a mouse. But keyboard navigation is non-existent. So you have to ask yourself is it worth it to go against decades of effort put in to standard web navigation for what gain? Obviously only you can answer that for your blog. I'm not having a go. But I will give you credit for the fact that it does work with Lynx!
    - TeMPOraL 7y ago
      By "keyboard" I assume you mean TAB-key-based navigation (I don't know of any other included in the browsers)? If so, it looks to me that links are in fact TAB-stops, but they're not being highlighted. It's something that should be solvable with a CSS adjustment.
      - quazar 7y ago
        If the links are not highlighted by default, then tab navigation is basically non-existent since I cannot see where I'd be redirected and I personally bother to write custom CSS only for the websites I visit very often. Is there an actual reason to disable highlighting? It lowers usability and accessibility, but I'm not sure what do you get in return?
alasdair_ 7y ago
>Because it's faster Did you read the article? The entire point was that “its faster” isn’t actually true.
blattimwind 7y ago
> Because it's faster. In my experience sites with these kinds of navigation are typically extremely slow with initial page loads taking anywhere from a couple seconds (bad) to 10-20-30 seconds, sometimes even a minute (on a 100 MBit/s connection) and subsequent navigations are often slow as well. It can be hypothetically faster, because you can theoretically get away with less data transfers and less client work, but in practice the exact opposites materialize.
- edflsafoiewq 7y ago
  Reminds me of JIT compilation, with the large initial load cost and the theoretical-but-mostly-unmaterialized reasons it could be faster.
deleted 7y ago
[deleted]
LudwigNagasena 7y ago
Do modern browsers really re-render everything without optimizations?
the8472 7y ago
In my experience for whatever reason github's turbolinks often take longer than opening the link in a new tab.
- jrockway 7y ago
  Github is simply a very slow website.
overgard 7y ago
> Furthermore, you don't lose state, which makes things much more simple. Nah, it makes it more complicated. You still have to handle reloads and back/forward, but now it's on you.
manigandham 7y ago
HN is very fast. Stackoverflow is very fast. Lots of other well engineered sites are very fast. As the article shows, browsers are well optimized and really don't download all the content again. In most cases it's just the HTML, which is streamed and rendered as it comes in. All the assets are cached, and scripts are even stored in compiled state to skip reparsing. Some sites might be slow at generating that HTML but then they would be equally slow at generating whatever JSON/API responses used in a SPA, along with loading all the heavy JS in the first place to render it all.
- fyfy18 7y ago
  This is what I don't really get. It seems like some people are under the impression that generating and parsing HTML is slow or takes a lot of resources. In almost all cases it's going to be faster and less resource intensive than generating JSON - especially if you are just using a templating language to interpolate some values. I agree that JSON could lead to less data being transferred over the wire, but that assumes your client already has cached the megabytes of JavaScript needed for you SPA. For something like a news site it doesn't make sense. On the client parsing is fast, but the slow part is the browser laying out the page and fetching new resources - but that is going to be slow anyway, even if you do client side rendering. To make that fast you need do something more intelligent than just rendering a different React component, as well as prefetching resources in the background. But how many SPAs actually bother trying to do that? I agree that SPAs have their place, and they have a lot of advantages over what we had before, but I just don't understand how it has seemingly become the default for any kind of web development - with such disregard for performance.
  - nathan_long 7y ago
    > I agree that JSON could lead to less data being transferred over the wire I haven't benchmarked the difference, but I bet HTTP compression removes most of the difference > but that assumes your client already has cached the megabytes of JavaScript needed for you SPA A cache that will need to be busted every time you deploy new code. You do deploy often, right?
spullara 7y ago
Try a blog not built on client side tech: https://www.lukew.com https://www.lukew.com - the page loads are insanely fast, just click around.
ijidak 7y ago
> Because it's faster That was the initial benefit. (Gmail, for example) Then everyone starting using the client-side model as the de facto architecture for every new website and web app. The old, "give a man a hammer" adage. Like any tool, it depends on the job. But sometimes a tool becomes so popular that it takes courage to choose not to use it. "Err...well... sure I can explain why I chose to go with plain old HTML.. (gulp)"
ZoomZoomZoom 7y ago
>>Imagine a simple image gallery. You just update the <img> tag, update the URL with the history API and everybody is happy. If you were to navigate via links, you get the same behavior. Please, don't! Just give me a page with thumbnails that are direct links to the original pictures! That's million times easier, works blazingly fast and I wouldn't need to spend so much time clicking multiple times to save each pic, which is the best case! The worst is serving me blobs of PNG instead of original pics. That's pure hostility.
noad 7y ago
It is not faster, ever. It is always snappier to render everything server side and avoid as much JS as possible. If you can consolidate the whole page down to a half dozen total HTTP requests or less that's ideal. The narrow case where you make an XHR call to just reload a small slug of data instead of the whole page effectively does not exist in the real world. I mean I'm sure a few developers have implemented that exact pattern a few times, I think I remember even doing it myself probably? But it's not something that actually happens. What's actually happening instead is people are just adding more and more intricate tracking and analytics to all these SPAs. The XHR call to reload a blurb of text kicks off three other XHR calls to register the event with the various analytics/advertising tracking partners. Oh and we're adding a new ad partner next week so make sure you refactor all the AJAX to register event handlers for all these new interactions. And can we add mouse position tracking too? I'm starting to see some pages break into the tens of megabytes of JS scattered across hundreds of files, nobody is paying any attention to what's fast. I'm not sure how you fix this, I've largely given up on the web. It's just a thoroughly terrible experience from top to bottom, and effectively unusable if you're a layperson.
yellowapple 7y ago
> Furthermore, you don't lose state I'd count breaking my back button or otherwise mucking with my browser history as "los[ing] state". Maybe we have different definitions of "you" in mind.

moron4hire 7y ago

It's probably not the network round trip or the actionable content making reloading the site so slow. It's almost certainly tracking scripts, unoptimized database queries, and unoptimized assets.

tiborsaas 7y ago
Sure, web performance is an afterthought at many places and the more people work on a certain project the worse it gets because each team has its own motivation, but they all have the same target to shoot at. I think there's a connection between the organizational structure and the bad frontend experiences and this is almost always overlooked in these discussions. This is no surprise of course, we only see the crappy end result and blame the technologies, but this is superficial. It's usually not the certain technology that's problematic (SPA, history api, react, angular, webassebmly...) but the use of them without understanding the problem first. That's why I find it funny when I constantly read general comments here like "SPA-s are the worst".
- ryacko 7y ago
  CSS doesn’t require javascript, and allows for nearly all the features of a SPA.
  - kowdermeister 7y ago
    Like plotting an equation to canvas? Editing video? Handling drag and drop events? I've seen that blog post where a guy demonstrated that many UI elements can be done with CSS, I like that. I try to do that myself as much as I can, but let's not pretend that CSS is a programming language and it can replace ANY JavaScript.
    - ryacko 7y ago
      It is debatable that CSS is or isn’t Turing complete, but as long as the task isn’t totally automated without user input, CSS could replace most Javascript.
- moron4hire 7y ago
  Yes, but equally so, replying to this email comments with "but page loads are slow" is not helpful.
- yc12340 7y ago
  SPAs are the worst, because companies deploy them to avoid separation of responsibilities and turn every employee into easily replaceable "full-stack developer". Unfortunately, a lot of people write terrible applications regardless of chosen technology. When this happens to purely server-side applications, the company is forced to optimize them to keep the hosting bill low — a positive feedback loop in action. SPA applications cause the opposite — companies move everything to client-side in order to reduce Amazon bills, and don't care if those client-side scripts are poorly optimized and contribute to global warming by causing hundred thousands machines to spin up their CPU fans. Clearly, there should be a heavy tax on single page apps. They are 1) addictive — by making more Javascript devs, who in turn write more Javascript websites 2) act as luxurious goods ("Look guys — we have created a new version of our website. It looks so cooool (but loads a bit slow)!") 3) have ugly externalities, completely ignored by most of their creators
  - kowdermeister 7y ago
    > companies deploy them to avoid separation of responsibilities and turn every employee into easily replaceable "full-stack developer" SPA-s are much-much harder to develop if more teams are working on it. So your first sentence makes little sense. > companies move everything to client-side in order to reduce Amazon bills This is never the reason why it happens. Seriously? The cost are not saved, just moved around. SPA-s are developed because they could provide a much better UX. As a side benefit, server side development becomes simpler by providing some REST or GraphQL API. You don't want to be in a place where tens of thousands of lines are generated backend side by backend developers. > client-side scripts are poorly optimized and contribute to global warming by causing hundred thousands machines to spin up their CPU fans. I appreciate your sense of humor :D

hombre_fatal 7y ago

A media gallery website is a good example of a use-case for client-side routing. I worked on a porn site that was basically an endless-scroll video gallery. Clicking a thumbnail opened the video in a modal overlay. All pages on the site were modal on top of the gallery in the background. You could deep link to a page and the gallery would load in behind it. It worked really well and had great UX. This generalizes to any website that has some sort of overall state between page transitions, like soundcloud.com playing a track as you click around.

testis321 7y ago
> I worked on a porn site that was basically an endless-scroll video gallery. So, if you're a horny teenager, you scrool down for a huge amount of time to find "the video" that will get you off... and you hear your mom coming up the stairs, Control+w (close tab), and when she goes downstairs again, you press Control+shift+t (reopen last closed tab), you're back at the beginning, and have to search for that video again? That sucks. Endless scrolling sucks. You go down and down and down, and something breaks (eg. bad wifi), and you lose your position, since refresh takes you back to top.
- frereubu 7y ago
  I hate infinite scroll with a passion. I've often been quite a way down someone's interesting Twitter feed and lost my place somehow, then just given up and gone somewhere else in frustration rather than trying to scroll down a few hundred tweets, waiting each however-many tweets for the next batch to load, just to get back to where I was.
  - TeMPOraL 7y ago
    Also the slowdown. Didn't matter whether I had 8, 12 or (currently) 32 GB of RAM; couple minutes scrolling down a Twitter or Facebook feed and the whole page slows down so noticeably that I simply give up. Also: something breaks, you press F5, and now the feed is gone, or is in a completely different place than it was before refresh. Infinite scroll should be labeled as dark pattern. Its only benefit is to the companies exploiting intermittent rewards; for users, it's just bad ergonomics and bad experience.

bloaf 7y ago

Do you have an example of a site which does it well?

kowdermeister 7y ago
There are many good ones, but after a quick bookmark search, this shop is done really well, imho: https://www.shopflamingo.com/ https://www.shopflamingo.com/
- thekingshorses 7y ago
  This is what makes it worse. If you scroll down on the page, and click on the link, it takes you to a new page. Works great. If you use browser back button, it takes you to the previous page, but scroll position is lost.
mceachen 7y ago
You can try PhotoStructure (disclaimer, I'm the author). It's an image gallery built with Vue and vue-router (for your images). If you look at the vue-router documentation, they've got some examples to follow. The back/forward buttons, command-click, and ctrl-shift-t work on all modern desktop and mobile browsers. I started with traditional page loads, but even with minimal css and no js, screen flashing between pages was prominent (especially on mobile), and visual transitions between pages (like swipe navigation where both prior and next page content is concurrently visible) is difficult.
M4v3R 7y ago
The blog of Svelte, the framework/compiler that was featured on HN some time ago works really well in my opinion: https://svelte.dev/blog https://svelte.dev/blog
- bloaf 7y ago
  I don't know if their javascript is to blame, but I got this when I tried to use the back button: https://imgur.com/a/YcRtDFj https://imgur.com/a/YcRtDFj

JulianMorrison 7y ago

The idea exists but it's clearly not true, except perhaps in specific, niche uses like re-rendering a continuously refreshed graph. Even for your image gallery, it makes for confusion. Back button does what? Shift-refresh does what? Just let the browser do what it does. If you want the images to render fast, use HTML 2. Writing a web app with server side pages forces you to think about where the state lives. This is a beneficial discipline.

kowdermeister 7y ago
The back button would do the same as it would do after you click a [next image] link :) Not sure about your point, the history API improves UX if you do it right: https://developer.mozilla.org/en-US/docs/Web/API/History_API https://developer.mozilla.org/en-US/docs/Web/API/History_API It does everything as hand written, pure HTML page would, just do it faster.
trop 7y ago
Google Maps would be the classic example of client-side refresh working so well that it's now the universal choice. At the time, it was a revelation, as the Mapquest-ish predecessors (if I recall) required a click and server-side refresh to scroll or zoom the map. Of course the revelation here was that <a> tags weren't what we needed to move a map, but rather a click-and-drag plus scroll-wheel behavior to explore a huge image at various levels of detail. If the server-side page-by-page navigation paradigm is a lousy fit for information delivered over the internet, then it may make sense to re-invent the page load. To use the language of a sibling comment, this brought things to a much more app-ish behavior. And eventually Internet maps have become, especially on mobile devices, an app. Hence the need to break server-side navigation may have foreshadowed the need to break out of the browser.
- JulianMorrison 7y ago
  I think this can be generalized as: if you need to break out of "click and wait a moment and see a changed screen" paradigm, for something like a continuously scrolling map or a smoothly flowing server load graph, then you can make good use of client-side loading. If you are just trying to re-create it, don't.

frereubu 7y ago

"You don't have to download all the content again" is also true if you version your assets and use a CDN with far-future expiry headers. If you need an HTTP connection to download a section of HTML for a new part of an SPA it won't be that much different from a full page of HTML, presuming you compress the transfer as you should. "Of course shitty implementations exist" is true of a non-SPA setup too.

daxterspeed 7y ago
While it's true that the browser won't have to download the content again, it will have to re-instantiate various resources (eg execute all JavaScript over again..., restart gifs). If implemented correctly, JavaScript navigation should seamlessly appear like normal navigation. Not supporting streamed requests is a serious drawback. Of course browsers have actually gotten pretty good at AJAX-like loading instead of completely re-rendering the page. These systems tend to rely on heuristics though, and I don't think there's any documentation for these, but even when these fail the browser tend to be more competent than even the best JavaScript solutions.
- frereubu 7y ago
  I think there are good use-cases for SPAs (Google Maps, for example), but the majority of cases that I've seen aren't good ones, and the extra complexity involved in managing state etc. far outweighs any marginal gains in not re-instantiating JS.
- zonidjan 7y ago
  > While it's true that the browser won't have to download the content again, it will have to re-instantiate various resources (eg execute all JavaScript over again..., restart gifs). Your JavaScript shouldn't be blocking page load anyway. Defer, defer, defer.
- manigandham 7y ago
  JS is cached in its compiled state in modern browsers. There is no download or parsing step for repeated loads.

mintplant 7y ago

All major browsers cache the relevant assets (images, CSS, JS) in-memory between navigations in the same frame/tab and origin (at least).

guggle 7y ago

> Furthermore, you don't lose state, which makes things much more simple. Or not... I think about infinite scrolls with no proper paging.

m-p-3 7y ago
New Reddit.. shakes fist

TeMPOraL 7y ago

> Because it's faster. The whole point of the article is that it's not true. It's not the only article that disproves it, and honestly, it's not difficult to notice it. Just go to any blog running off a static site generator; loading times of pure HTML webpages on good connection are so fast they whole thing outruns client-side page switches even if the page is already in memory.

StavrosK 7y ago
Case in point, navigation on my site is pretty fast (to me, at least) and doesn't use much JS at all: https://www.stavros.io https://www.stavros.io (I promise I'll reply to your email soon)
- jspash 7y ago
  I'll admit it is pretty fast. Assuming you are using a mouse. But keyboard navigation is non-existent. So you have to ask yourself is it worth it to go against decades of effort put in to standard web navigation for what gain? Obviously only you can answer that for your blog. I'm not having a go. But I will give you credit for the fact that it does work with Lynx!
  - TeMPOraL 7y ago
    By "keyboard" I assume you mean TAB-key-based navigation (I don't know of any other included in the browsers)? If so, it looks to me that links are in fact TAB-stops, but they're not being highlighted. It's something that should be solvable with a CSS adjustment.
    - quazar 7y ago
      If the links are not highlighted by default, then tab navigation is basically non-existent since I cannot see where I'd be redirected and I personally bother to write custom CSS only for the websites I visit very often. Is there an actual reason to disable highlighting? It lowers usability and accessibility, but I'm not sure what do you get in return?

alasdair_ 7y ago

>Because it's faster Did you read the article? The entire point was that “its faster” isn’t actually true.

blattimwind 7y ago

> Because it's faster. In my experience sites with these kinds of navigation are typically extremely slow with initial page loads taking anywhere from a couple seconds (bad) to 10-20-30 seconds, sometimes even a minute (on a 100 MBit/s connection) and subsequent navigations are often slow as well. It can be hypothetically faster, because you can theoretically get away with less data transfers and less client work, but in practice the exact opposites materialize.

edflsafoiewq 7y ago
Reminds me of JIT compilation, with the large initial load cost and the theoretical-but-mostly-unmaterialized reasons it could be faster.

deleted 7y ago

[deleted]

LudwigNagasena 7y ago

Do modern browsers really re-render everything without optimizations?

the8472 7y ago

In my experience for whatever reason github's turbolinks often take longer than opening the link in a new tab.

jrockway 7y ago
Github is simply a very slow website.

overgard 7y ago

> Furthermore, you don't lose state, which makes things much more simple. Nah, it makes it more complicated. You still have to handle reloads and back/forward, but now it's on you.

manigandham 7y ago

HN is very fast. Stackoverflow is very fast. Lots of other well engineered sites are very fast. As the article shows, browsers are well optimized and really don't download all the content again. In most cases it's just the HTML, which is streamed and rendered as it comes in. All the assets are cached, and scripts are even stored in compiled state to skip reparsing. Some sites might be slow at generating that HTML but then they would be equally slow at generating whatever JSON/API responses used in a SPA, along with loading all the heavy JS in the first place to render it all.

fyfy18 7y ago
This is what I don't really get. It seems like some people are under the impression that generating and parsing HTML is slow or takes a lot of resources. In almost all cases it's going to be faster and less resource intensive than generating JSON - especially if you are just using a templating language to interpolate some values. I agree that JSON could lead to less data being transferred over the wire, but that assumes your client already has cached the megabytes of JavaScript needed for you SPA. For something like a news site it doesn't make sense. On the client parsing is fast, but the slow part is the browser laying out the page and fetching new resources - but that is going to be slow anyway, even if you do client side rendering. To make that fast you need do something more intelligent than just rendering a different React component, as well as prefetching resources in the background. But how many SPAs actually bother trying to do that? I agree that SPAs have their place, and they have a lot of advantages over what we had before, but I just don't understand how it has seemingly become the default for any kind of web development - with such disregard for performance.
- nathan_long 7y ago
  > I agree that JSON could lead to less data being transferred over the wire I haven't benchmarked the difference, but I bet HTTP compression removes most of the difference > but that assumes your client already has cached the megabytes of JavaScript needed for you SPA A cache that will need to be busted every time you deploy new code. You do deploy often, right?

spullara 7y ago

Try a blog not built on client side tech: https://www.lukew.com https://www.lukew.com - the page loads are insanely fast, just click around.

ijidak 7y ago

> Because it's faster That was the initial benefit. (Gmail, for example) Then everyone starting using the client-side model as the de facto architecture for every new website and web app. The old, "give a man a hammer" adage. Like any tool, it depends on the job. But sometimes a tool becomes so popular that it takes courage to choose not to use it. "Err...well... sure I can explain why I chose to go with plain old HTML.. (gulp)"

ZoomZoomZoom 7y ago

>>Imagine a simple image gallery. You just update the <img> tag, update the URL with the history API and everybody is happy. If you were to navigate via links, you get the same behavior. Please, don't! Just give me a page with thumbnails that are direct links to the original pictures! That's million times easier, works blazingly fast and I wouldn't need to spend so much time clicking multiple times to save each pic, which is the best case! The worst is serving me blobs of PNG instead of original pics. That's pure hostility.

noad 7y ago

It is not faster, ever. It is always snappier to render everything server side and avoid as much JS as possible. If you can consolidate the whole page down to a half dozen total HTTP requests or less that's ideal. The narrow case where you make an XHR call to just reload a small slug of data instead of the whole page effectively does not exist in the real world. I mean I'm sure a few developers have implemented that exact pattern a few times, I think I remember even doing it myself probably? But it's not something that actually happens. What's actually happening instead is people are just adding more and more intricate tracking and analytics to all these SPAs. The XHR call to reload a blurb of text kicks off three other XHR calls to register the event with the various analytics/advertising tracking partners. Oh and we're adding a new ad partner next week so make sure you refactor all the AJAX to register event handlers for all these new interactions. And can we add mouse position tracking too? I'm starting to see some pages break into the tens of megabytes of JS scattered across hundreds of files, nobody is paying any attention to what's fast. I'm not sure how you fix this, I've largely given up on the web. It's just a thoroughly terrible experience from top to bottom, and effectively unusable if you're a layperson.

yellowapple 7y ago

> Furthermore, you don't lose state I'd count breaking my back button or otherwise mucking with my browser history as "los[ing] state". Maybe we have different definitions of "you" in mind.