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

101–110 of 137 posts

Re: Scaling React Server Side Rendering

#101

Post by bernawil »

irq11 wrote: post #95
bernawil wrote: post #88

Earlier quoted context omitted.

On a bad connection, I'd pick a react SPA with a slow upstart over a classic server-side rendered one any day all things being equal. With the react app there's a chance I'll have the js already cached and I'm only fetching the data. With the SSR I'll probably be fetching data and view continuously.

Nonsense. You haven’t experienced a slow connection recently, or you’re just loading the same sites over and over again. People keep asserting it’s impossible to do all of the stuff we were doing on a daily basis in 2012, without the magic of megabytes of client-side code.

> or you’re just loading the same sites over and over again.

That's right, I am loading the same sites again every day consuming different data. Both for work and fun. That was the whole point.

Re: Scaling React Server Side Rendering

#102

Post by irq11 »

BinaryIdiot wrote: post #100
lewisjoe wrote: post #94

This looks like a great piece of article. Kudos to the people who wrote it because the most sure-shot problem in SSR is running to scaling issues and this is a much needed one. But here's an unpopular opinion: Server side rendering shouldn't even be a thing. Running a language as dynamic as Javascript on servers, is at best - a problem that can be dealt with, but not necessarily the solution. I'm saying this as a ful…

Rather than running JS on the server, one way I found things to be effective is using any server side templating capability to basically "bootstrap" what the JS might typically do on start-up. So the server renders you a page that looks well formed and then the JS hooks into it for client interactions. The issue that can be runned into here is possibly duplicating efforts on the server and JS side. You can keep them…

This is called “progressive enhancement”, and is, in fact, the way that you’re supposed to write webpages: they should come pre-rendered, and only if the client has JS enabled do you enable more dynamic features. You fall back to full pageloads to handle form submissions with not-very-clever coding, and can usually preserve most of the functionality of a webapp even without JS.

Until about 5-6 years ago, this was the way people tried to write webapps (they didn’t always get there, but at least they aimed for it). It’s really startling that it’s something that people have already forgotten.

It really isn’t terribly difficult to do this. Frameworks like Rails make it pretty easy to do, out of the box.

Re: Scaling React Server Side Rendering

#103

Post by arvinsim »

irq11 wrote: post #102
BinaryIdiot wrote: post #100

Earlier quoted context omitted.

Rather than running JS on the server, one way I found things to be effective is using any server side templating capability to basically "bootstrap" what the JS might typically do on start-up. So the server renders you a page that looks well formed and then the JS hooks into it for client interactions. The issue that can be runned into here is possibly duplicating efforts on the server and JS side. You can keep them…

This is called “progressive enhancement”, and is, in fact, the way that you’re supposed to write webpages: they should come pre-rendered, and only if the client has JS enabled do you enable more dynamic features. You fall back to full pageloads to handle form submissions with not-very-clever coding, and can usually preserve most of the functionality of a webapp even without JS. Until about 5-6 years ago, this was the…

> This is called “graceful degradation”,

Isn't that strategy "progressive enhancement"?

https://www.w3.org/wiki/Graceful_degradation_versus_progress...

Re: Scaling React Server Side Rendering

#104

Post by irq11 »

arvinsim wrote: post #103
irq11 wrote: post #102

Earlier quoted context omitted.

This is called “progressive enhancement”, and is, in fact, the way that you’re supposed to write webpages: they should come pre-rendered, and only if the client has JS enabled do you enable more dynamic features. You fall back to full pageloads to handle form submissions with not-very-clever coding, and can usually preserve most of the functionality of a webapp even without JS. Until about 5-6 years ago, this was the…

> This is called “graceful degradation”, Isn't that strategy "progressive enhancement"? https://www.w3.org/wiki/Graceful_degradation_versus_progress...

Yes, it is. I corrected my post around the same time you replied. I’ve colloquially used the term I originally cited, but the correct term is progressive enhancement.

Re: Scaling React Server Side Rendering

#105

Post by draw_down »

nyczomg wrote: post #68
yoz wrote: post #4

This is a fantastic article. I was daunted when I saw the length, but everything about it - the prose style, the mixture of drawings, the pace - led me through and out with a whole load of valuable lessons about load balancing, caching, isomorphic rendering and more. Thank you! One question for the author, if they're reading: how did you prep for writing this piece and gather the story details? It's quite a journey,…

Totally agree. If I had to criticize anything, I'd say the title is too specific to react. As a dev who avoids react/js/node as much as I can, I still found lots of very interesting and informative stuff in there. Probably helps that it was very well written. If for some reason you're a bitter backend dev who doesn't use react, but are reading this comment... Do yourself a favor and read the article. Really good stuf…

I think it’s ok to write about what you actually work on, instead of attempting to universalize it for the benefit of people who actively avoid what you work on.

Re: Scaling React Server Side Rendering

#106

Post by chrismmay »

Nice article. It does a great job of explaining just how much unproductive work Google has created for developers. They created SPAs with Angular in 2010, but 10 years later, their search engine still can't properly index client-side-rendered SPA applications, forcing you to jump through all these hoops, to undo the benefits of client-side rendering, just to fix what they should be fixing with their search engine. It's truly insane. What a waste of time and energy. I hope they are working on a solution. I guess this represents an opportunity for a competitor to come in and do it better.

Following your journey through troubleshooting load balancing and caching brought back memories for me. I don't know what you're using for caching, but JSR-107 has been around for nearly 20 years. You might want to check out https://commons.apache.org/proper/commons-jcs/. I know it's not Javascript, but it will solve your caching problem in an orderly way. You shouldn't have to start from scratch on caching. You might even consider telling your content creators something like "updates to the site will only take effect the next day" so you can just invalidate the entire cache once a day and be done with it. Keep it simple.

Re: Scaling React Server Side Rendering

#107

Post by hnbreak »

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…

> Try using client-side rendered website on a cheap Android phone...

Just not true. We test all your react sites with $100 Android phones. They render them all fine and fast.

Re: Scaling React Server Side Rendering

#108

Post by hnbreak »

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…

Thought it's known that SSR is better at SEO.

Re: Scaling React Server Side Rendering

#109

Post by hnbreak »

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.

yes they call this rendering now but just in the context SSR vs SPA

Re: Scaling React Server Side Rendering

#110

Post by hnbreak »

People debate SPA vs SSR without any context. Both have their use case:

Everything before a login => SSR, everything after => SPA.

Why? SSR is proven to be much better at SEO. But SPAs offer best UIs. Nobody wants to click through stuttery SSR dashboards in 2019, wait for page loads, submits, etc. People prefer slick UIs, that was one of the reasons DigitalOcean got big (because of their then stunning dashboard or after-login-experience [1]) and hence every other hoster copied their interface.

[1] DigitalOcean's dashboard experience was for a long time the main teaser (as an animated gif/video) on their landing page.

Post reply on HN