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

81–90 of 137 posts

Re: Scaling React Server Side Rendering

#81

Post by StreamBright »

bcherny wrote: post #42
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, provid…

> dramatic reduction in server resource consumption

What is the the measurement of dramatic reduction?

Re: Scaling React Server Side Rendering

#82

Post by nkingsy »

sgslo wrote: post #18
encoderer wrote: post #16

Earlier quoted context omitted.

If you have a small website google will render your JavaScript for every crawled page. For large websites only a sample of pages are fully rendered. Your seo will suffer.

SEO alone is a poor reason to use server side rendering. Services like https://prerender.io/ completely solve SEO for SPA's and can be as cheap as $0 per month. Compare that to dozens/hundreds of hours of engineering time spent setting up an SSR implementation; it is a no-brainer.

This advice is badly out of date. Crawlers no longer respect the fragment meta tag, so unless the pretender is actually served, this service does nothing

Re: Scaling React Server Side Rendering

#83

Post by nkingsy »

aplummer wrote: post #37
a13n wrote: post #27

Earlier quoted context omitted.

This is probably the worst possible takeaway from this article. > not use javascript for everything Using JS for frontend + backend has significant advantages. Your developers only need to know one language/codebase. You don't need to hire/maintain separate frontend/backend teams who need to figure out how to coordinate with each other. > actually generate html That's what server-side rendering does. > expecting peop…

> You don't need to hire/maintain separate frontend/backend teams who need to figure out how to coordinate with each other. In my experience the language is very little of what makes a frontend / backend developer, and you still need separate teams.

Seriously! I find backend work unintuitive and colorless. Others on my “full-stack” team have about as much love for the frontend as I do the backend.

Re: Scaling React Server Side Rendering

#84

Post by noahtallen »

jaequery wrote: post #74

How about just generate and serve static pages? Aren’t most apps on Netlify and serverless doing this now?

If you want an “app,” it makes sense to do a lot of stuff client side — especially if you’re trying to edit or create something in the app (I.e. Google Docs, Gutenberg editor in WordPress, Microsoft office online apps). If you want a landing page for your new startup, static pages on a serverless architecture make way more sense. It really depends what the use case is.

Probably more of the confusion lies in the line between those things — like a CRUD app or a dashboard or management tools. You could do them server-side for better initial performance, but you could also get better interactivity client-side.

I think a lot of new projects go towards the interactivity and “slick UI” side of things which is partially why we see more focus on client-side things these days. Speaking to myself (a full stack dev with a front end focus), we front end devs would really benefit from caring about performance and stability more.

Re: Scaling React Server Side Rendering

#85

Post by jborichevskiy »

arkwright wrote: post #38
zyngaro wrote: post #23

Great read ! What did you use to draw the diagrams ?

Diagrams are drawn with a Pilot Fineliner (greatest pen ever) in an artist's sketchbook. I then take a photo with my phone, crop to size, and run the image through a two stage conversion process. First ImageMagick converts the image to grayscale and cranks up the contrast. Second, Potrace converts the grayscale bitmap to an SVG. This was my hack way of avoiding the purchase of a tablet. One interesting consequence of…

I can't get my diagrams to look a tenth as good as yours, even with a tablet and undo. Nice job!

Re: Scaling React Server Side Rendering

#86

Post by tyingq »

randall wrote: post #79
Twirrim wrote: post #26

Earlier quoted context omitted.

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.

Not exactly the same, but there's a throttling feature in Chrome dev tools.

Re: Scaling React Server Side Rendering

#87

Post by bernawil »

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…

> With this type of contingency plan, I don't see any reason to use server-side rendering at all

A case of vital context missing. Ever tried something like Next.js? It's a react framework for client + server-side rendering. What's really cool about it is that it does SSR for the initial view and the client-side react picks it up from there. It doesn't sound very impressive like that but where it blew my mind was when I realized that I could save URLs for some deeply nested view in a react site, enter that URL later and I'd get an instantaneous SSR'd view seamlessly.

I guess what I'm trying to say is that some tech is cool like that, not really a contingency plan but a plan.

Re: Scaling React Server Side Rendering

#88

Post by bernawil »

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…

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.

Re: Scaling React Server Side Rendering

#89

Post by irq11 »

bernawil wrote: post #88
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…

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.

I love the JS experts on HN, telling everyone 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.

Re: Scaling React Server Side Rendering

#90

Post by minitech »

eliseumds wrote: post #70

I developed the JS architecture of https://www.productreview.com.au and we have faced tons of issues getting SSR right, but it was worth it. We're getting more than 10M pageviews a month and I'd like to share our experience: * Upgrading NodeJS indeed gives us massive performance boosts, but apply with caution. Ideally have a set of visual regression tests just to be safe * Profile your NodeJS code just like you do wi…

> * Properly serialize your JSON strings. That's what we use: https://gist.github.com/eliseumds/6192135660267e2c64180a8a9c....

That doesn’t look like “properly”. The double escaping is overcomplicated and no safer compared to a direct

  window.__productreview_data = ${escapedReduxStateJsonString};
(and forgets about \v, maybe others), the transformation doesn’t preserve “Closer to correct:

  JSON.stringify(data)
    .replace(/\u2028/g, '\\u2028')
    .replace(/\u2029/g, '\\u2029')
    .replace(/
Better, if you put the JSON in an inert (type="application/json"), it’s only necessary to escape < (or /<[/!]/g). This is a good idea so you can use restrictive CSPs.
Post reply on HN