[bearjaws]

Just use React and any backend?

If you have time for the project, you have time to learn a proper setup that every company for the past 15+ years has used.

SSR is quite frankly a performance myth if you distribute your frontend on a CDN. Ultimately your cloud functions reach out to your database, that is centrally located... SEO work well without SSR for the most part.

[9rx]

> Ultimately your cloud functions reach out to your database, that is centrally located...

A big difference is that your code running in the datacenter should always be well connected to the network. The user running your code out in the middle of nowhere teetering on the edge of available mobile coverage... Not so much. SSR means the user can begin after one round trip instead of, at bare minimum, two (and more realistically at least three – HTML, JavaScript, and data), which becomes significant as latency rises.

Although I would agree that the cases where you actually need that are not as common as we like to think, and even where justified a lot of developers are bound to screw it up such that the app isn't usable without multiple round-trips anyway. It is certainly something you should think long and hard about. It is not tradeoff-free.

[qudat]

As far as I’m concerned, SSR is completely over-hyped and adds a ton of complexity to your project. All these search indexers are all running headless chrome anyway so the SEO argument is largely false now.

Running vite and deploying a fully static site that interacts with an API is, to me, vastly simpler to reason about than a blackbox react framework (next.js) sitting on top of a black box rendering library (react).

Having a “backend for your frontend” is pure overhead for most projects. I’ve been building on the FE for a decade and have only needed SSR once and certainly never needed some hybrid static/dynamic/islands setup.

If you need SSR, you need it, but I find SPAs to be vastly superior in terms of dev speed and overall performance of an app once the JS has loaded.