7 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 MrRadar 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.
How many sites actually do this? And how much additional bandwidth (and battery life for mobile devices) does doing this consume?
> We can provide better visual feedback that loading is taking place and a transition is about to occur. And we don't need to load the entire contents of the page — often, we can make do with a small bit of JSON because we already have the JavaScript for the page.
In my experience sites that do this are almost universally slower and less responsive than sites that just use normal links. Maybe that's just confirmation bias and I just don't notice it as much on sites that do it well, but a particularly egregious example of this is Reddit's current mobile site vs their old i.reddit.com mobile site (which I use exclusively (despite it missing a number of newer features and having a lot of minor bugs the newer site doesn't) because it's way way faster).
- AlexandrB 6y ago> In my experience sites that do this are almost universally slower and less responsive than sites that just use normal links. Yup. A car analogy: "Instead of waiting for the driver to turn the steering wheel before causing the car to turn, we put the car on the back of a flatbed truck that tracks driver behaviour and tries to predict their intent. Then we can start turning the flatbed truck a little bit sooner to improve user experience."
- Isomorpheus 6y ago> Maybe that's just confirmation bias and I just don't notice it as much on sites that do it well This seems to me to be the key phrase. I sympathize with all the "JS has gone too far" people in this thread. I also hate bloated JS apps. But, "almost all SPAs are bloated trash" is a distinct claim from "SPAs are intrinsically trash". In my experience it is possible to have lean, high-performance, accessible SPAs without too much developer difficulty. Svelte (created by the author of this article) is one framework in this space, although I think there are better approaches.
- rephrase 6y agoDo you know of good SPAs? Sites that feel snappy even though they're SPAs. Most sites I visit that are SPAs are consistently slow so I've learned to make the same association: SPA = bad.
- kixiQu 6y agoIt seems like this whole discussion would work better with examples where people are willing to say "This is done well, and it has these benefits from having been done in this way"
- rephrase 6y agoYup.
- evilduck 6y agoWe've been experiencing sluggish pages since long before JS really became a thing too. PHP and a slow inline query to render results has been a possible problem for literally decades. Do you investigate all the fast snappy sites you visit to confirm they aren't single page apps? What about the slow pages that aren't SPAs (most every news site)? It seems like anyone who wants to dislike JS and/or SPAs can easily confirmation-bias their way into believing it.
- rephrase 6y agoThat's why I asked for examples. I want to know what are the good examples. Someone mentioned the main react site. Seems like a good place to start.
- robertoandred 6y agoHow about the React website? https://reactjs.org/docs/getting-started.html https://reactjs.org/docs/getting-started.html
- 6y ago