Comment by onion2k

> The distinct advantage of an SPA is that, done correctly, cached data lets you render pages instantly.

Yeah, but full page caching is a thing, and in my experience, teams writing traditional server-rendered pages are much more aggressive in their use of response caching than are teams writing JSON APIs. Honestly, a Rails/Django/Laravel app with smart caching headers and a Varnish instance in front feels more reliably instantaneous than the bespoke caching solutions each SPA seems to invent for itself.

Have you tried to use a heavily SPAed site from a slow, distant (high latency), or metered connection? A SPA that works and feels great from a big city quickly becomes unbearable when internet access isn't as ideal. There are ways to handle this nicely, but maybe 5% of devs actually think about and test that, and no PM will allocate sprint time for it.

> Who CARES if the SPA had to make 3xRTT in the background, if it can serve the next page up instantly because that data is already present and cached, it's a huge win.

The data is never in the cache. It is for a developer because they forget to clear their caches when testing. For most users the data will not be cached unless they're sitting on the SPA all day.

So when the user doesn't have data cached that 3xRTT on their spotty 4G signal the SPA pattern is of no help. Not everyone is sitting still on great WiFi. Someone's cellular reception can go from great to unusable just walking down the street.

> done correctly

Big assumption. This is what the whole discussion is about. Doing "correctly" an SPA is incredibly expensive.

I can also assure you that when an MVC application is done correctly you can have an equally good user experience.

> The server rendered app will ALWAYS have to wait at least 1xRTT for every new render. The SPA does not.

This is an outdated idea of how server rendered apps work. See Unpoly, HTMX, LiveWire, Hotwire, etc.

I'm personally using Livewire. I make server request in only 2 situations. 1) When going to different pages (I'd need that anyway with an SPA given I need "SSR") and 2) When I'd need to write or read data from the server, which with an SPA would mean I need an API call anyway. Every other interaction is done with Alpine, 100% client side.

Unless their cache is cold and then they navigate back before your first render completes. Often we are not the sole source of a piece of information and first load time counts.

> The server rendered app will ALWAYS have to wait at least 1xRTT for every new render. The SPA does not.

Not necessarily. I think you're conflating caching/fetching and rendering here. You can cache rendered views in the same way you'd cache the data for those views.

Turbo does this, for example. When you navigate to a cached page it will display the page from the cache first, then make a request to update the cache in the background. So it's similar to what you describe, but with server-rendered content.

Preloading is a browser-native feature, you don't need a SPA for that. And just as often you can't know in advance what data will be requested by the user.

What they're meaning is that the total time is longer for the SPA if you don't go all out (and nobody does).

SPA:

    1. get html from server (1 roundtrip)

    2. get resources (js/jpg/movies/gifs/favicon/...) from server (1 roundtrip)

    3. get ajax calls from server (1 roundtrip)

    4. process answer from server + update page (not a roundtrip, but not zero)

Vs traditional:

    1. get html from server (1 roundtrip)

    2. get resources from server (1 roundtrip)

Also if there are sequential ajax calls required to build the page (like a list -> detail view), it goes up a lot without speed oriented (very bad code style) API design. For instance you need a separate "GetListOfUsersAndDetailsOfFirstUser()" (or more general "getEverythingForPageX" calls). You can't do "GetListOfUsers()" and "GetUserDetail()" separately.

So to match traditional webpage total load time you cannot do any ajax calls in your SPA until after the first user action. And even then, you only match traditional website performance, you don't exceed it.

Time until the first thing is on screen however, is faster in SPA's. So it's easy to present "a faster website" in management/client meetings, despite the SPA version actually being slower.

You can make SPAs faster than traditional websites ... but, for example, you cannot use javascript build tools. Since you need to do the first calls server-side and have javascript process them, and only send the result of the preprocessing, and the resulting dom to the client, after optimization and compression. After that you need to then do image inlining, style inlining, etc. I know react can do it, but does anyone other than facebook actually do that?

If one style of writing applications is far more prone to having “bad software”, consider that this is a valuable signal about the difficulty of using that style effectively. SPAs require you to take on ownership of more hard to debug challenges and that's an important factor to consider when selecting tools.

The GP was not saying "bad software is bad"; they pointed out a lot of footguns that are introduced by going the SPA route. "More code -> more (opportunities for) bugs" is the truism at play here.

I don't know. I'm not very familiar with Next.js (I'd heard about it but never really looked into it much). Your response inspired me to investigate, and I found an article by a Remix founder about the differences [1]. It's obviously biased, but maybe still interesting. It looks like there was an HN submission and a bit of discussion, too.

There's a bunch of other comparisons out there, too.

[1]: https://remix.run/blog/remix-vs-next [2]: https://news.ycombinator.com/item?id=29983950