Refreshes can be very fast, and often essentially invisible in modern browsers, when you don't bloat the page unnecessarily, but I think AJAX still has a use for things like the voting button on HN or "add to cart" buttons in a web shop. It would be annoying to lose the scroll position (and perhaps other state) for each item you want to add/upvote.

(Although modern sites that try to sweep latency under the rug by immediately updating the state on the client side and later reverting the change when the server responds are perhaps more annoying.)

"Refreshes can be very fast, and often essentially invisible in modern browsers"

That's thanks to a fantastic browser feature that was introduced a few years ago that hardly anyone knows about: Paint Holding - https://developer.chrome.com/blog/paint-holding/

"... where the browser waits briefly before starting to paint, especially if the page is fast enough. This ensures that the page renders as a whole delivering a truly instant experience."

This is why you don't see flashes of a blank white page while a new page is loading on most sites these days.

Also browser refreshes should definitely not lose scroll position, though I can understand how with full ones the former position might not be the "correct" one any more with dynamic content like HN... or substack comments (and how did those manage to be so slow and buggy displaying what is almost exclusively text ?!)

Not a refresh of the same page, but if you perform some action (e.g. adding an item to a shopping card), that would imply a POST request which then (according to the common pattern) redirects to the original page... so then you do lose the original scroll position, I think?

Latency between page going blank and FCP, poor recovery mechanisms. Significant number of users is still on occasionally bad connections (e.g. on a train, walking into the part of the building with poor signal etc). If interaction in SPA does not work, they can try again, because they still have the UI. If page goes blank and does not load, not every user will recover from this.

I'm not convinced that it is... but it's not as smooth as client load-once rendering can be.

What is/was painful was, as an example, the first versions of ASP .Net Web Forms, where every client action was a full server round-trip... Server-rendered Blazor over the wire (not local or in-office server) is roughly as painful by today's standards.

I do think that it's a mix... start with basic html and enhance, or start with a component toolkit with client rendering, and inject server donut or other pre-rendering. With Cloudflare and Deno, I think the latter definitely has some traction.

I find it much less smooth having a webpage consuming constant CPU.

That's a different issue. There's no reason CPU consumption should be high when you aren't interacting with an application.

Most of the time there is no need for "it" to be an application, when it can be a page with some buttons.

There's theory, and there's practice....

If you have a complex user interface with the possibility that many parts might be in use at any given moment, full page refreshes mean your users could lose work.

This would definitely be a bad user experience.

But it doesn't mean refreshes are bad, just that the architect of that application hasn't factored them into the user experience appropriately, or they've made their interface unnecessarily complex.

All modern browsers have enough tools baked in that we can work around this without reinventing the execution and rendering pipeline (e.g. localStorage).

if the page is large and you only need to bring back a little data it's probably better to just grab the little data. or upvote so your just sending a little bit of info back to the server.