Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scaling React Server Side Rendering

arkwright.github.io

Post reply on HN
Print view View original

71–80 of 137 posts

Re: Scaling React Server Side Rendering

#71

Post by platform »

wayneftw wrote: post #6

There was no mention of why server-side rendering was needed at all. Based on my companies research Google and Bing do just fine without it. > when the server is under high load, skip the server-side render, and force the browser to perform the initial render. With this type of contingency plan, I don't see any reason to use server-side rendering at all. We build all of our sites and apps with React and don't do it a…

Article mentions that server-side rendering was needed for SEO (Search engine optimization) and first-page load speed

(normally server-side rendering first-page loads faster because it is pre-rendered (and often cached) ).

>"... SEO was a very important consideration — we had full-time SEO consultants on staff — and we wanted to provide the best possible page load speed, so server-side rendering quickly became a requirement. ..."

Re: Scaling React Server Side Rendering

#73

Post by Tade0 »

simonw wrote: post #10
wayneftw wrote: post #6

There was no mention of why server-side rendering was needed at all. Based on my companies research Google and Bing do just fine without it. > when the server is under high load, skip the server-side render, and force the browser to perform the initial render. With this type of contingency plan, I don't see any reason to use server-side rendering at all. We build all of our sites and apps with React and don't do it a…

Try using client-side rendered website on a cheap Android phone on a 3G connection sometime - or even a cheap Android phone on LTE. That's how most of the world's population will experience your site. I'm baffled that so many sites have invested in multiple megabytes of JavaScript to render their pages. It's like our entire industry has forgotten how to build sites that can be used by anyone who's not on an LTE iPhon…

Recently, due to a router placement issue I used up all my mobile data so my connection was slowed down to 16kbps.

Most sites/apps don't work at all at this speed with the notable exception of Hacker News and Facebook Messenger.

Re: Scaling React Server Side Rendering

#75

Post by no_wizard »

chrshawkes wrote: post #34
adossi wrote: post #17

Earlier quoted context omitted.

One of the main reasons I never bothered to learn React was that using Razor syntax in .cshtml on my ASP .NET projects has all the convenience of react with no client-side overhead. However I understand there is some benefit to delegating some of the work to clients considering the power of modern devices.

Whether Razor or Server Side React, it's the same thing. Both are compiled and produced on the server and sent to the client. No difference except that react is a much better template engine.

You had me until that last part.

Why is React superior to Razor Templates (or for that matter, Razor pages) for server side templating?

I support the assertion that it’s a good paradigm for creating consumable SSR templates I just don’t see anything that empirically cuts it above Razor other than if you know JSX/JavaScript it’s obviously more natural but I’m assuming that’s taken for account here

Re: Scaling React Server Side Rendering

#76

Post by KaoruAoiShiho »

wayneftw wrote: post #6

There was no mention of why server-side rendering was needed at all. Based on my companies research Google and Bing do just fine without it. > when the server is under high load, skip the server-side render, and force the browser to perform the initial render. With this type of contingency plan, I don't see any reason to use server-side rendering at all. We build all of our sites and apps with React and don't do it a…

In practice google does not really work with SPAs. This is why internet research can be dangerous.

Re: Scaling React Server Side Rendering

#77

Post by StreamBright »

superkuh wrote: post #5

The easiest way to do this is to not use javascript for everything in the first place and to actually generate html instead of expecting people to run your code, then having to do it yourself in a convoluted workaround when they won't or can't.

Exactly. It is pretty amazing how developers went from server side rendering to SPAs just to get back to server side rendering few years later. The projects I have been working on never went down the SPA path so there is no need to do SSR in JS and doing it in other languages like Rust, Java or C++ gives you significantly higher base line performance (that you can optimise further).

Re: Scaling React Server Side Rendering

#78

Post by mattmcknight »

wayneftw wrote: post #6

There was no mention of why server-side rendering was needed at all. Based on my companies research Google and Bing do just fine without it. > when the server is under high load, skip the server-side render, and force the browser to perform the initial render. With this type of contingency plan, I don't see any reason to use server-side rendering at all. We build all of our sites and apps with React and don't do it a…

Do people call returning HTML/CSS/images from a server "rendering" now? The browser still "renders" the HTML into a visible UI.

Re: Scaling React Server Side Rendering

#79

Post by randall »

Twirrim wrote: post #26
simonw wrote: post #10

Earlier quoted context omitted.

Try using client-side rendered website on a cheap Android phone on a 3G connection sometime - or even a cheap Android phone on LTE. That's how most of the world's population will experience your site. I'm baffled that so many sites have invested in multiple megabytes of JavaScript to render their pages. It's like our entire industry has forgotten how to build sites that can be used by anyone who's not on an LTE iPhon…

Facebook decided to tackle this by having traffic shaping one day a week. On that day of the week, traffic shaping means the developers get to experience the Facebook site as if they were on high latency / low bandwidth connection.

This doesn't exist anymore. :( I just tried to see if I could opt into it, but it caused issues so we have to do it on a machine by machine basis.

Re: Scaling React Server Side Rendering

#80

Post by crooked-v »

mattmcknight wrote: post #78
wayneftw wrote: post #6

There was no mention of why server-side rendering was needed at all. Based on my companies research Google and Bing do just fine without it. > when the server is under high load, skip the server-side render, and force the browser to perform the initial render. With this type of contingency plan, I don't see any reason to use server-side rendering at all. We build all of our sites and apps with React and don't do it a…

Do people call returning HTML/CSS/images from a server "rendering" now? The browser still "renders" the HTML into a visible UI.

In this context, 'render' means transforming React (or similar framework) output into a DOM tree, plus the magic that goes into rehydrating dynamic elements once the static copy of the page is loaded.

The benefit of that is getting all the effects of 'just plain HTML' while still being able to dynamically update parts of the page, and doing the entire thing in a single framework such that (if you do it right) your code doesn't have to explicitly do anything to specially handle the two different use cases.

Post reply on HN