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

41–50 of 137 posts

Re: Scaling React Server Side Rendering

#41

Post by TheSpiciestDev »

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…

I haven't seen anyone reply to you yet specifying social media and SEO.

For example, copying a route from your SPA and pasting it into Twitter, Facebook, Slack, Teams, etc. Preferably you want the copied page's title, description and icon and not just your SPA's generic info.

Re: Scaling React Server Side Rendering

#42

Post by bcherny »

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.

OP answers this in the article:

> Isomorphic rendering is a huge simplicity booster for developers, who for too long have been forced to maintain split templates and logic for both client- and server-side rendering contexts. It also enables a dramatic reduction in server resource consumption, by offloading re-renders onto the web browser. The first page of a user’s browsing session can be rendered server-side, providing a first-render performance boost along with basic SEO. All subsequent page views may then fetch their data from JSON endpoints, rendering exclusively within the browser

Re: Scaling React Server Side Rendering

#43

Post by ng12 »

sandov wrote: post #32
ng12 wrote: post #25

Earlier quoted context omitted.

Are you advocating for avoiding dynamically generated pages altogether? I agree that would be simpler but try winning that argument with the bizdev folks :)

I think he/she advocates for websites to be generated on the server (if they're dynamic) and not passing on that burden to the browser. Specially if the browser language was created to add drop-down menus and cool snow effects, not to generate a complete html website.

That's why I'm confused, that's exactly what this article is about. You're using React SSR to do the same thing you would do using RoR or JSP... unless the gripe is specifically with JavaScript as a programming language.

Re: Scaling React Server Side Rendering

#44

Post by tannhaeuser »

a13n wrote: post #30
Vesuvium wrote: post #20

Earlier quoted context omitted.

That's exactly the point he's making. If you use a frontend js framework and you have to do SSR, then there's no longer any reason to use a JS frontend framework, because the reason they were made was to offload to clients the rendering, at the price of more complexity. Back then, the cloud was not a thing yet, there was no Docker, no Kubernetes, no nice APIs to start instances, so it made sense to offload some compu…

The reason React was made is because it's an easier way to reason about apps at scale, with many components and people working on them. As a result, there will be less errors and your team can move faster. It has nothing to do with offloading rendering to the client.

How is "reasoning" about apps at scale easier with React vs static or classic server-side HTML rendering where everything is addressed by a URL?

Re: Scaling React Server Side Rendering

#46

Post by danpalmer »

a13n wrote: post #24
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…

The two main benefits of SSR are SEO and performance. SEO: If you don't server-side render your website, your SEO will certainly suffer. Google says they execute your JS, and to some extent they do, but your ranking will be worse and fewer pages will be scraped. We experienced this first hand. Perf: User will stare at a blank page while they wait for your JS to download and execute. On a slow connection this could be…

To expand on this, Google execute your JS, but in a slightly odd JS environment (I.e. randomness isn’t random, time might not be correct, etc). They give each site a CPU time budget, and your JS execution eats into this.

If you have 5 pages that take seconds to render you might be fine, if you have 100k pages that take 50ms to render you might be in trouble.

Some of the detail of this is exposed in the webmaster tools that Google provide.

Re: Scaling React Server Side Rendering

#47

Post by danpalmer »

Twirrim wrote: post #22
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…

Client side rendering sucks for anyone on high latency networks (a significant potential customer base). From an SEO perspective it leaves you subject to whenever the search engine has rendering capacity available. There's some good write up here: https://medium.com/@benjburkholder/javascript-seo-server-sid... Essentially content that requires client side rendering gets stuck waiting for Google to have resources avai…

As a plus to the SSR part, you’ll also likely have any API resources either already loaded out of the database, or very close in latency to the renderer, whereas on the client you could easily be 100ms of latency plus other overheads away.

Re: Scaling React Server Side Rendering

#48

Post by tannhaeuser »

Scarbutt wrote: post #19
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.

Creating solutions for auto-created problems.

Indeed. The whole point of the web, as the name implies, was to have a simple portable HTML frontend, with a wide choice of backends that could be easily bolted on top of existing data and code bases. There never was a lack of native frontend frameworks for sophisticated interactive apps.
Post reply on HN