4 ms·
> When I tap on a link on Tom's JS-free website, the browser first waits to confirm that it was a tap and not a brush/swipe, then makes a request, and then we h
by quantummkv 6y ago
> When I tap on a link on Tom's JS-free website, the browser first waits to confirm that it was a tap and not a brush/swipe, then makes a request, and then we have to wait for the response. With a framework-authored site with client-side routing, we can start to do more interesting things. We can make informed guesses based on analytics about which things the user is likely to interact with and preload the logic and data for them. We can kick off requests as soon as the user first touches (or hovers) the link instead of waiting for confirmation of a tap — worst case scenario, we've loaded some stuff that will be useful later if they do tap on it.
What? The solution to making a website fast is to crunch analytics (presumably on the client and in JS, all of which has to be loaded beforehand for this to work) and then try to predict what the user is going to do on the website, anticipate it, and start loading, even when it might go waste?
Wastage of network bandwidth aside, Speculative Execution destroyed the chip performance in the last two years and opened up a whole lot of scary security holes, some of which may never be fully patched without performance hits. And the bright idea is to do that in the browser?
- frosted-flakes 6y agoIt's hardly crunching analytics. If there's a call-to-action on the homepage, it's likely that the user will click it, so we should pre-load it. I believe Gatsby will pre-load any link that's visible in the viewport by default$
- quantummkv 6y agoBut what if the user does not click on it but clicks on something else? Then we are back to square one with a lot of effort for nothing. > I believe Gatsby will pre-load any link that's visible in the viewport by default$ If it does that, then no wonder that the original article was completely right. On a page with 10 visible links in the viewport, I will only navigate to one or maybe I won't navigate. Then why the hell is my battery, network bandwidth, etc is being used for it what is essentially 90% wastage?
- the_gastropod 6y agoYes, this. I about fell out of my chair reading this paragraph. In these discussions, I find defendants of these SPA designs to almost always point to vague points about "rich UI" or "highly interactive", or make up complete hypotheticals like this example of pre-loading likely-to-be-clicked links. Show me the code. Show me the crazy-fast link-click-predicting website that does this and loads faster than, say, HackerNews. It's good to see the pendulum swinging back to some semblance of sanity on this topic. The past ~5-10 years of the SPA being the default choice has been a wild time. I couldn't be happier that it's starting to receive some widespread criticism.
- rich_harris 6y ago> Show me the crazy-fast link-click-predicting website that does this and loads faster than, say, HackerNews. https://hn.svelte.dev/ https://hn.svelte.dev/ is a Sapper implementation of Hacker News. It uses the preload-on-hover/touch technique described in the article. In my experience it does indeed feel faster than Hacker News, despite basically being something I threw together one weekend
- krapp 6y agoWow. It loaded the 1000+ comment Ask HN thread "What's your quarantine side project?" in less than a second for me. I've seen HN itself choke on smaller threads.
- rich_harris 6y agoUpdate: since posting this it looks like the site is being hugged to death — might need to upgrade something in GCP :) Either that or it's a coincidental problem with https://api.hnpwa.com/v0/ https://api.hnpwa.com/v0/
- robertoandred 6y agoNooo!! You're going against the JS BAD narrative! Stop that right now!
- the_gastropod 6y agoCredit where credit is due: this is excellent work! Very impressed.