It does break search. A traditional SPA returns to the client an empty HTML page (except for header stuff) and a script to parse. The script then populates the DOM with the elements, problem is that crawlers are not really good at waiting for the "render" to happen, and running JavaScript just to see what's in the page opens a whole other can of worms. SPAs are awful for search engines and that's why we get the hybrid monsters that Next.JS, Nuxt, SvelteKit and co. produces nowadays (not saying they are bad from a user perspective though, much prefer web apps made with them over client-side rendered SPAs).

We spent the last decade trying to fix the whole mess that client-side "rendering" created in the web, we'll probably spent the next decade trying (and failing) to standardize things such as web components, declarative shadow DOM, among other things. That's because we as developers keep insisting in complexity: hydration, SPAs, bundlers (and in consequence bundle bundlers such as Vite). The only true solution is to bet in simplicity, but that's not sexy, and sex sells.

In conclusion: The React revolution and it's consequences have been a disaster for the human race.

The SEO argument is a strawman. Large swaths of the Internet return a blank page if you try to access them with JS turned off. Are you saying search engine crawlers haven't figured out how to deal with that?

There is nothing inherent in SPAs that make load time slower. If your REST API takes 5 seconds to serve up JSON, what's to say your SSR rendered page won't also take 5 seconds?

   > Are you saying search engine crawlers haven't figured out how to deal with that?

Except for Google which has spent a tremendous amount of effort on that, yes I am.

   > There is nothing inherent in SPAs that make load time slower.

I never said they are. The difference is only for crawlers which now have to run JavaScript whereas before they could just retrieve the document and index it as it was served to it instead of trying to determine when the SPA has done the full loading of the page.

Not convincing. Even a PHP page wouldn't be indexed as it was served if it loads JS scripts. And if your page isn't running JavaScript, comparing SPA and SSR is moot. One could just use one of the hundred odd HTML templating tools to produce a static page.

Please read a bit of the history of this debate:

https://stackoverflow.com/questions/36702789/google-crawler-...

Till today the Google Crawler is the only one that gets even near good search results of SPAs. That's because they have to run a full browser to load every page to parse it. Every. Single. Page. That's why it is hard to do correctly. Read a bit about their current approach here:

https://developers.google.com/search/docs/crawling-indexing/...

Specially:

   > Keep in mind that server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript.

Recently in 2019 Bing Bot just gave up and is using the same approach a Google:

https://blogs.bing.com/webmaster/october-2019/The-new-evergr...

So nowadays having a SPA isn't as bad for SEO as it used to be, but again, and I'll keep nailing on this, that is only because we spent the entire last decade throwing millions of dollars and hundreds of hours of engineer time to make SPAs a viable option.

Saying that an SPA returns an empty HTML page is the old days. If you're already aware of Next, Nuxt, etc. then you know that the most popular frameworks of each ecosystem already support SSR whether you're building for an MPA, SPA or hybrid.

Next basically is React and the React team implicitly admits this.

Traditionally Next.JS isn't really a tool to develop a single page application (although you could CSR every page if you want to), since single page applications are... single page. These are all multi page full stack frameworks that make use of incremental static regeneration and hydration to have the best of both worlds.

We agree though, it's just a naming thing really. I make the distinction like this because traditionally a SPA can simply be served by a CDN since it's simply a single file, meanwhile all of these frameworks either require a server to render pages on request or prerender all the applicable pages and leave a few of them to totally client-side "render".

Also note how Vercel (at the time called Zeit, mostly known for Now) called Next.JS back in 2018 when they originally released it:

https://web.archive.org/web/20180628030830/https://nextjs.or...

   > Next.js is a lightweight framework for static and server‑rendered applications.