[Rauchg]

Interestingly, I have the exact opposite bet: “SPAs were a zero interest rate phenomenon”. Putting the burden of compute on clients, and shipping slower apps for the sake of DX and convenience. Customer-first wins.

Looking forward to see how this plays out.

[zarzavat]

SPAs are faster than SSR because you can choose whether to incur network latency or not.

For example, let’s consider a site with two pages. In the SSR case, if I click the link to page 2, then I have to wait a whole network roundtrip for the page to appear.

In the SPA case you can decide when you want to load the content for page 2: with page 1 (if it’s a small amount of content), if the user scrolls to a certain point, … it’s completely up to you. You can cleverly hide the latency so that when the user does navigate to page 2, it’s instant.

[Jnr]

You can do what you described with Next.js and latest React easily. In addition, it will also help with SSR where it makes sense for speed and performance.

Building site with Next.js makes it simple to get a good perceived performance, the framework handles it out of the box.

[tqkxzugoaupvwqr]

MPAs can do the same trick. Use JavaScript to add a <link rel=prefetch> element to prefetch a URL. Or just serve your server-side rendered page with this element included to prefetch the next page. When the user navigates to the next page, it’s instantly shown.

https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...

[pjmlp]

Nope, you do a bit of DHTML to update the only section that matters.

[zarzavat]

Isn’t DHTML just 00s speak for SPA? Not much difference between an accordion and react router, except the history API.

[pjmlp]

For selective Ajax calls actually, not a full dynamic site rendered on the client to display static text.