[voidr]

If you want to optimise for SEO you might want your content to be rendered on the server, however: rendered on the server is not the same as being sent down in the initial HTML payload. Server components are not convenient to use, because they cannot be interactive, even code that you would expect to work does not work on the server.

There are good parts like server actions, however they are plagued with very strange limitations making them not so useful.

If you want to statically generate websites and want to use React, NextJS can be a good choice, however for complex web applications I find that it's not ambitious enough to justify even the extra compile time that I get from its tooling compared to Vite.

[lelanthran]

> If you want to optimise for SEO you might want your content to be rendered on the server

Why would you optimise for SEO on a webapp? What's the use-case there?

If you're not writing a webapp, then any server side rendering would do and client side components aren't needed anyway.

[enra]

You wouldn’t but many of the largest users of these frameworks are actually e-commerce sites, not applications.

[Cthulhu_]

Can confirm, that was the last project I worked on that had SSR; fancy product website / e-commerce, combined data from a CMS-as-a-service and a webshop-as-a-service, rendered pages in one go using Gatsby, published it. I believe that was the best of both (SSR / webapp) worlds, in that it was both fast and indexable in a static context, and if the user had JS enabled and the page was hydrated, navigation was super fast and lightweight because only some JSON went over the line.

I'm not sure if I would do it again though, but we'll cross that bridge when we get to it.