Anything that actually changes the data requires a server roundtrip. The point is that it's faster and simpler to just have the server render the entire HTML and replace that rather than making an API call with client-side JS rendering.

>Anything that actually changes the data requires a server roundtrip

I mean, of course, but clearly I've outlined a situation where you can easily prefetch some objects to have an instant user experience. These are plentiful.

Additionally, you enable responsiveness in other ways server rendering can't accomplish with an SPA. You can display loading status of async resources, you can optimistically display changes so the user can begin editing another piece of data without waiting for latency-bound UI, etc..

Finally, "simpler" is a hard sell. Simpler for who? Someone who is writing a simple HTML data table page? Yes. For someone who is building a collaborative graph editor? Give me a break.

This is my point this whole comment thread - the anti-SPA crowd here sometimes hates JS and browsers so much they are willing to completely sacrifice user performance inside application use-cases because they find the idea of an SPA unappealing. It's pretty absurd, facile really, to claim "it's faster AND simpler".

Where's the prefetching? The table loads with the page. Loading it after with JS will only go slower.

> "server rendering can't accomplish with an SPA"

Again, you don't need a SPA to have some interactive DOM manipulation. Nobody is saying everything requires fresh HTML from the server, but something like jQuery Datatables will give you 99.99% of instant client features while working with server-rendered tables. htmx.js is another great library that solves most use-cases.

> "For someone who is building a collaborative graph editor?"

Obviously not, because that's one of the few times where a SPA is needed.

> "the anti-SPA crowd here sometimes hates JS and browsers so much"

What's with the extremes? Nobody is against SPAs or JS or browsers. In fact we want browsers to be used for what they do best, which is rendering URLs into pages very quickly. SPAs make a tradeoff in trying to emulate most of the browser performance and reliability in return for complex interactivity. The issue is that most sites don't need that interactivity, and what little they do need can easily be done with much less.

> What's with the extremes?

I'm not the one speaking in extremes. This is a quote:

> The point is that it's faster and simpler to just have the server render the entire HTML and replace that

That's childish analysis.

Yes, I said that in the context of this thread, specifically the GP post that said:

> "a large html table rendered on the server into the DOM directly was orders of magnitude faster "

Ignoring all context and calling this a "childish analysis" does nothing to further your arguments, and is yet another example of your comments going to the extremes.

You show a dogmatic support of SPAs without any consideration for the repeated statements that they are overused and not fit for the majority of the interactivity that people use them for. If you refuse to accept this than there's nothing more to discuss.

Seriously, you don't really seem to know what you're talking about.

You can do it either way, and your particular example is a really poor reason to have a SPA.

As multiple people are trying to tell you.

I don't know what I'm talking about, yet I build slick UIs for a living. Ok.

You are advocating for every action to take a server round trip to render, a client UI that consists of some hobbled-together mess of client JS, endpoint-rendered HTML, and worst-of-all extra server infra in order to facilitate it, when your client presents you with a perfect execution environment for a single application to transform data into semantic UIs.

I doubly enjoy that you didn't answer my earlier interpretation of your proposal, nor name any specifics of how you work, instead opting to swing back by once other people had sufficiently derailed the conversation.