Hacker News Reader

Comment by gatnoodle | Hacker News Reader

It's frustrating that when people discuss React on the server or frameworks like Next.js, the conversation rarely acknowledges the performance cost that comes with Server-Side Rendering (SSR). The excitement tends to focus on the benefits like SEO and initial page load performance, but the limitations and potential drawbacks of running JavaScript server-side are often overlooked.

As traffic increases, the server's ability to handle requests diminishes, especially under high loads with complex rendering. This is exacerbated by the fact that each request often requires repeatedly rendering the same React components from scratch, rather than reusing client-side resources.

View on HN

> , the conversation rarely acknowledges the performance cost that comes with Server-Side Rendering (SSR)

This conversation is so old that most of the people having it already know this implictly so don't consider it even worth mentioning. I know I never do, because I started with things like php which works like that.

I've met plenty of devs who have never seen php and who consider server side rendering to be magic because "Vercel takes care of it".

I was just explaining why it's not brought up that often. I wasn't making a claim as to whether it should be more often.

Hah! Fair enough.

I feel like the rush of developers in the last 5-8 years means a lot of history is just unknown.

People get all weird when I mention I self host all my projects for $10 a month on a machine I administer.

Half a core on a modern cheap VPS is equivalent to the massive server machines of the past!

well of course, but no matter what you do a "server" takes increased load as traffic increases (maybe it's just cheaper and simpler if it's a managed cdn)

you always have the option with react on the server of returning a minimal skeleton and client rendering the rest. the point is you can make those decisions case-by-case

I wrote a blog post about this a few years back and got lambasted for daring to question the wisdom of SSR.

That same post still gets plenty of views from people looking up on Google if they should use SSR though.

Doing everything client side means scaling asset delivery is trivial. A potato running nginx can serve an absurdly large number of concurrent users fetching the same static payload.

Those backend apis need their own scaling story, and different types of APIs have very different scaling stories.

What doing some rendering server side and some client side can do is create confusion as to what is done where. (And with particularly bad settings even leak api keys, oops!)

I had dev who praised next, turned out he had no idea when his code ran on client or server.

One leaked API key later, OpenAI bill goes brrrrr.

I keep being puzzled by the SEO argument because google indexes client-side rendered pages just fine. Are there really SEO problems that are solved by SSR?

The initial page load argument is real, but is sort of a self-imposed problem because page loads would be fast if there wasn’t this massive bundle of JS code that’s 95% infrastructure and 5% actual site content.

> I keep being puzzled by the SEO argument because google indexes client-side rendered pages just fine. Are there really SEO problems that are solved by SSR?

In theory, yes, in practice no. I've deployed SPAs for landing pages as well as server-side rendered or statically generated pages, and there was a huge difference in indexing and SEO between the two. Google can say they render client-side pages just the same, but I have not found that to be true at all.

Reply on news.ycombinator.com