[amw-zero]

I agree with the sentiment of what you're saying, but I don't agree with the premise that there are no use cases for single page apps. You can achieve a decent UX for some applications by using small amounts of vanilla JS, but it's simply not possible to avoid re-rendering the entire page without using XHR requests at some point. That is how the browser is designed, fundamentally. Because it wasn't designed as an application platform, it was designed as a document platform.

But some products are actually better as applications, not interconnected documents. For those applications, the browser fights you every step of the way, because that's not what it's designed for. You simply can't compare the UX of document-based web applications to native clients.

An SPA is just the web approximation of a native client. Your application truly runs in the client process continuously, so rendering transitions happen smoothly instead of blank pages and jumping transitions. Everyone would benefit from understanding more and using that to simplify all areas of the tech stack, but the experience that an SPA offers is simply not possible otherwise.

[systemvoltage]

SPA is a poor approximation of a native client with a hugely bloated browser stuck in some level of the abstraction, bypassing native app libraries, design sensibilities, typography guidelines and accessibility by implementing some UI framework that was developed by people that are entirely unqualified for it. Have you looked it the guidelines for UI development, say for MacOS? Here you go: https://developer.apple.com/design/human-interface-guideline...

PWAs, browser apps - they bypass all this work from professionals and give it in the hands of an unequiped developer. Oh god.

A browser is a window, an area of the screen that is allowed to do whatever it wants in a sandbox mode. This is a terrible idea. It becomes complete wild-wild-west.

[dexen]

>it's simply not possible to avoid re-rendering the entire page without using XHR

Wrong on two separate levels.

First up, technologies like iframes, frames, and objects/embeds allow that just fine; you can use at least some of them without any JS whatsoever.

Secondly, with avoiding re-rendering you end up avoiding a 200ms ... 500ms load+render of simple full page, at the cost of doing 2...5 seconds of gradual load+render of various bits and pieces. Bits and pieces that often are so unwieldy they cause widgets & content to load gradually, jump around, and sometimes even get hidden behind a loader. While the CPU fan keeps whining at full revs.

The solution became worse than the problem it purported to solve, and your users pay the price in wasted time + RAM + electricity.

If you pay even a little attention to order of loading you can avoid FOUC entirely. If you pay a little attention to defining sizes of leading elements, you'll have constant layout of the top part of the page, and avoid flash of white background. If you use anchors here and there your user will be scrolled to the proper position.

Yes your page can easily look as if it got only updated with JS after doing a full load+render.

The technology is already in the browser; no need to approximate it with three layers of JS.

[amw-zero]

You can’t compare the UI of a web page built in this way to an SPA or a native client. Re-rendering an entire page on every interaction is strategically never going to get you the same experience. I understand wanting to be a browser purist, but web applications have had pretty laughable UX compared to native apps of even 20 years ago.

I mean look at an iOS app designed by Apple. I always reference the AppStore app itself. You simply can’t build that app as a web app, certainly not by using iframes as a “solution.”

[grey-area]

You don't need an SPA to use XHR, and your description of the SPA experience for the end user is a fantasy - there's a reason pretty progress bars are popular in SPAs, and it's not because of fast state changes, quite the reverse.

[amw-zero]

It's funny, your example actually shows the primary benefit of an SPA, and doesn't do anything to show any downsides. A progress bar is a perfect example. You can't show a progress bar with HTML. You would have clicked something, and a new page would be rendered entirely. In the time it took to create the new page on the backend, the user would be staring at either a white screen or the current page. If they're looking at the current page, they probably think the application is malfunctioning, as no user feedback was given to their action.

Whereas, with an SPA, you can _instantly_ show a progress bar, at least indicating that something is going on. And, the very fact that you're showing a progress bar means that the client side rendering isn't the slow action, it's retrieving something from the server. So, the UI was as interactive as possible.

[grey-area]

This is an amazing feature you simply don't need on the majority of web apps, because a) the browser has a loading indicator and b) most web apps are fast enough to not need to tell the user about it, they just load new pages in milliseconds instead.

An in-page progress bar is in most cases a failure of UX, not a success.

[FragrantRiver]

I'm pretty sure I can find more pages that take more than 200 milliseconds to load than ones that are under.