My argument for SPAs rests on the completely subjective yet I feel incredibly powerful impact of latency. When anything takes more than 50ms to react, it becomes mentally jarring to the user. Whether it is typing in an SSH session, clicking a menu with a mouse, auto-completing a box, etc - all these things generate a completely different human response and relationship with the application if they get below that threshold of latency. In my experience, it's nearly impossible to get non-SPAs across that threshold for large sections of their functionality, while for SPAs it becomes more or less the default. So people can make all the technical arguments they want, but to me the human factor of that subjective feeling trumps it all.
That's not possible for SPAs outside localhost. Every single SPA i know is clunky, including gmail which is probably one of the most barebones. The lack of visual indication that something is happening or downloading alone is infuriating with SPAs. Most of them reinvent the browser in a very poor substitute that invariably fails to both be practical , and to mimic a native mobile app (i think the latter is the reason for so many SPAs.
SPAs are like CGI.. you only notice it when it is bad. I can assure you, you use many SPAs that are not slow and clunky, you just don't realize they are SPAs
I notice all of them , 100% of the time. Twitter has a fairly good one, but even that s very clunky. I'm not saying they are all slow, but they are clunky, jumpy and unpredictable, which in many ways is worse than a webpage like HN that is 100% consistent, but sometimes times out. Predictability for me is more important than pay-it-later responsiveness. E.g. when i press the Pay button i 'm OK with waiting 20 seconds for the payment to process. What's unacceptable is the button standing still, not doing anything until a few seconds later, at which time i ve pressed it 10 times.
Because like other commenters that chimed in, I can notice most SPAs, and all SPAs I've used had annoying performance problems. By problems I don't mean a sudden request that takes half a second, but that every UI interaction feels subtly slow.
I don't know where people get these performance targets of "below 100ms and users won't notice". I notice. I notice if UI responses take longer than two-three animation frames, the same way I notice when a game is running at 20 FPS and not 60 FPS.
Fastmail is laggy in places, but mostly OK. But I'm surprised at you choosing Google Office as an example. Google's office suite is a poster child of slow, clunky SPAs.
>including gmail which is probably one of the most barebones.
And yet, it still uses 130 flipping megabytes of RAM, more than Youtube does, as well as more CPU than Youtube does at idle, as well as requiring several seconds to "start up" when first opening a tab. Ridiculous.
I think gmail is a bit of a parody of itself nowadays. For extra hilarity someday, try pressing "c" for compose as the site is loading. Literally seconds to get a compose window showing.
Most of these SPAs you speak about have loading spinners, grayed-out placeholders, all sorts of tricks to make it feel like you're in control while the fetch() roundtrip to populate the page data completes. The borders of your screen may not change, but the page filling with elements after a delay can be just as jarring.
If a non-SPA page loads near instantaneously because the client-side rendering isn't bloated, it can feel just as good as an SPA with spinners.
You can also use tools like turbolinks the author recommended, to turn your non-SPA into an SPA.
Displaying a loading spinner in under 50ms while waiting for a 500ms request to complete doesn't necessarily build a strong relationship.
SPAs can start off with the good intention of being low-latency and responsive. But when you're backed by a web server, you still have to account for it though optimistic rendering, prefetching, and loading states. Getting it right can be an excellent UX, but it's easy to get very wrong.
I've designed and programmed highly interactive SPAs for customers large and small, and the reaction is invariably "I can't believe this is a website, it feels like an app". Being non-technical, they can't put their finger on it, but I know that while the base design plays a part, so does the concrete UI implementation.
I wonder how many of the people crapping on SPAs are actual front-end or full-stack app devs, or otherwise people developing very close to the UX.
I'm sure there are some disgruntled UX devs who are running back to SSR, but when I come to the bimonthly "SPA sucks" thread on HN, for the most part it feels to me as though the critiques are coming from people for whom UX and front-end development are secondary concerns.
> Being non-technical, they can't put their finger on it
This is an interesting perspective. To me, SPAs blur the line between what's happening locally and server-side, so my impatience with slow functions on an SPA page is much greater than the same thing happening on a SSR page. Maybe it's just my conditioning to expect things on a single page to work much quicker as opposed to moving between pages.
IMO, well-designed SPAs should make use of the context-switching function of a complete page fetch in situations where the user might need to wait a relatively longer time for something to load instead of loading bars/spinners.
It's a crap threshold. 100ms is 10 FPS. You can most definitely tell when something is updating at 10 FPS, vs. 20 FPS (50ms). Movement stops being jarring at ~30 FPS (33.3ms), but you can most definitely tell apart that and 60FPS (16.6ms).
When anything takes more than 50ms to react, it becomes mentally jarring to the user
Yes, but you often pay a huge penalty on the first page load, which for many use cases is the most important. I'd be so happy with a turbolinks version of GMail.
