Hacker News Reader

Comment by kennu | Hacker News Reader

Isn't the whole point of server-side rendered React to render it just once, when building the website, and then serve it as static HTML/JS/CSS assets using a static webserver?

View on HN

That's one use case.

The other is for performance/seo where the initial markup for the app is generated and served to the client as HTML, then the React app bootstraps on the client and takes over managing the DOM.

This is what I'd like to see a performance comparison for.

1. Initial load using client-side vs server-side rendered. (Server-side should be faster.)

2. Warm load using client-side vs server-side rendered. (Client-side should be faster.)

Comparing to static is interesting, but not really an option if you're serving dynamic content.

That would be one way of using it. Though practically speaking a very limited way of doing it and not very useful for a lot of dynamic sites.

More and more sites are using React for general purpose server-side rendering, even if the site isn't a single page app. I believe that's what the article is targeting.

How do you do that with dynamic content?

In my view the user-specific parts and frequently updating data should be rendered on the client side. The pre-rendered HTML should contain the less-frequently changing information that is important for SEO.

Given the option, and pretending it were just as easy to implement either, why would you wait until the document loads to fetch resources via Javascript when you can render the content on the server?

The article points out one downside: React's render-to-string faculties are slow.

Reply on news.ycombinator.com