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

The Performance Cost of Server Side Rendered React on Node.js

malloc.fi

Post reply on HN
Print view View original

91–100 of 134 posts

Re: The Performance Cost of Server Side Rendered React on Node.js

#91

Post by mottomotto »

timr wrote: post #87
mottomotto wrote: post #80

Earlier quoted context omitted.

Well that is a whole other debate. The best thing about React is common patterns. Second best is the availability of components. I've worked with JavaScript for a long time -- the Backbone.js days were painful. It was easy to accidentally leak event binds, code yourself into a corner, etc. The jQuery days were almost better in some ways but still had some real pain points. You missed that I'm working on SaaS and a we…

"You missed that I'm working on SaaS and a web application" I didn't miss that. SaaS means "software as a service", and doesn't imply anything about the complexity of your UI. Plenty of SaaS companies use server-side rendering. Likewise, "web applications" were being written long before React was a thing. Also no, you don't have to do a full server round-trip for every click, any more than you have to send JSON back…

But I have zero use for SEO-friendly pages -- all my client-side pages are behind a login-wall. It isn't one big blob of JSON -- it's multiple endpoints. With HTTP/2, multiple small requests are fast.

> build the few dynamic elements on their pages with a simpler, more robust technology

This is a horrible idea that has worked poorly for so many projects. At one potential employer, they did this and their app had a message view with a read count. They didn't care the read count didn't update -- you had to reload the whole page for it to update. Those are the kind of inconsistencies that the above approach encourages because it's not cohesive.

Can you do it? Yes. Should you? No, not in my book.

> low latency, URL routing, progressive enhancement

I've got low latency, I have client-side URL routing, I have no need for progressive enhancement -- it's just more complexity that neither I nor my customers need. These are all great ideas if you have a public website and need to cater to a wide range of visitors. I don't. I'm very happy to be able to only have to support the last couple major versions of each browse.

Re: The Performance Cost of Server Side Rendered React on Node.js

#92

Post by zghst »

anatoli wrote: post #88
laurencerowe wrote: post #85

It would be worth verifying that NODE_ENV=production is set during these benchmarks (I see no mention in either the article or the source repository.) Running in development mode has a significant performance impact. Edit: This PR shows that is likely to be the case. Running in production mode along with some other minor changes shows React running at 88% the speed of Pug. https://github.com/janit/node-templating-ben…

NODE_ENV=production definitely wasn't set based on some basic testing I did (that's my PR there), which accounts for the atrocious performance. Also, the React component is created on each request instead of just being created once. Unless one's goal is to specifically colour the perception of React, I don't understand that decision alongside the code for Pug which precompiles the template a single time. (Also declar…

It’s common in the dev (esp. JavaScript) community. The wild rush to be first to discover or disagree for karma points on the internet.

Re: The Performance Cost of Server Side Rendered React on Node.js

#93

Post by lucaspiller »

spinlock wrote: post #70
mottomotto wrote: post #68

If you're on the fence about server-side rendering being needed for your webapp don't do it! As a team of two with one engineer, I decided YAGNI and instead focused on the responsiveness of the React and Redux-based web application. It is very snappy to load and our (paying) customers are happy. You might not need SSR. I don't. I expect there will be more work to optimize it and eventually it'll be obviously a good i…

Also, if you _need_ SSR, rails might be a better approach. It's too bad the author didn't include it in the benchmark.

We did this recently with a small app that needs to be fast. The relatively simple page that you see when you first visit the site is rendered with plain old Rails, then when the user interacts with the page (based on DOM addEventListener hooks) it causes additional React components to be mounted and rendered.

Originally I’d hoped to be able to render a basic version of the page with Rails, then ‘enhance’ it with React - ie render For with Rails, then when React has loaded, replace it with a React component. But I couldn’t find any details on using it this way, and given time constraints choose the simplest option.

Re: The Performance Cost of Server Side Rendered React on Node.js

#94

Post by velmu »

anatoli wrote: post #88
laurencerowe wrote: post #85

It would be worth verifying that NODE_ENV=production is set during these benchmarks (I see no mention in either the article or the source repository.) Running in development mode has a significant performance impact. Edit: This PR shows that is likely to be the case. Running in production mode along with some other minor changes shows React running at 88% the speed of Pug. https://github.com/janit/node-templating-ben…

NODE_ENV=production definitely wasn't set based on some basic testing I did (that's my PR there), which accounts for the atrocious performance. Also, the React component is created on each request instead of just being created once. Unless one's goal is to specifically colour the perception of React, I don't understand that decision alongside the code for Pug which precompiles the template a single time. (Also declar…

Hello Anatoli. Thank you for this. It was clearly an oversight on my part, not intentional to make React look bad. I have added a note on the article and will run the tests with the correct settings and your PR with further optimisation.

Re: The Performance Cost of Server Side Rendered React on Node.js

#95

Post by shams93 »

mottomotto wrote: post #68

If you're on the fence about server-side rendering being needed for your webapp don't do it! As a team of two with one engineer, I decided YAGNI and instead focused on the responsiveness of the React and Redux-based web application. It is very snappy to load and our (paying) customers are happy. You might not need SSR. I don't. I expect there will be more work to optimize it and eventually it'll be obviously a good i…

No matter what system you use for server rendered pages most likely you will have to hit a database just to render out the site. These days that's a bad idea when we should be building progressive web apps that can fetch and cache content as needed from services but the entire app can live offline and even cache data in local storage to enable it to have at least limited offline functionality.

Re: The Performance Cost of Server Side Rendered React on Node.js

#96

Post by jeswin »

velmu wrote: post #94
anatoli wrote: post #88

Earlier quoted context omitted.

NODE_ENV=production definitely wasn't set based on some basic testing I did (that's my PR there), which accounts for the atrocious performance. Also, the React component is created on each request instead of just being created once. Unless one's goal is to specifically colour the perception of React, I don't understand that decision alongside the code for Pug which precompiles the template a single time. (Also declar…

Hello Anatoli. Thank you for this. It was clearly an oversight on my part, not intentional to make React look bad. I have added a note on the article and will run the tests with the correct settings and your PR with further optimisation.

Then you should withdraw the article until you get real numbers. This utterly misleading data (as of now) is going to be picked up by search engines and other blogs.

Add: on a positive note, this aspect of React is worth benchmarking. Thank you for that.

Re: The Performance Cost of Server Side Rendered React on Node.js

#98

Post by merb »

ralusek wrote: post #30
foota wrote: post #17

Earlier quoted context omitted.

Does anyone actually use vanilla JavaScript string literals for all their backend rendering?

Couldn't tell you, but it's not really relevant. The post I'm replying to says that it should come as no surprise that NodeJS template rendering is slow, and I just meant to point out that the article is quite specifically isolating ReactJS rendering as slow, and has nothing to do with NodeJS or JS at all.

well depends, I doubt that native js string interpolation is written in javascript at all. so basically it is javascript, but since you are using the native interpolation you probably go trough a c interface. or some kind of extremly optimized path.

Re: The Performance Cost of Server Side Rendered React on Node.js

#99

Post by sandGorgon »

mottomotto wrote: post #68

If you're on the fence about server-side rendering being needed for your webapp don't do it! As a team of two with one engineer, I decided YAGNI and instead focused on the responsiveness of the React and Redux-based web application. It is very snappy to load and our (paying) customers are happy. You might not need SSR. I don't. I expect there will be more work to optimize it and eventually it'll be obviously a good i…

unless your startup's life and death depends on SEO - in which case, do it !

Re: The Performance Cost of Server Side Rendered React on Node.js

#100

Post by lmm »

timr wrote: post #73
mottomotto wrote: post #68

If you're on the fence about server-side rendering being needed for your webapp don't do it! As a team of two with one engineer, I decided YAGNI and instead focused on the responsiveness of the React and Redux-based web application. It is very snappy to load and our (paying) customers are happy. You might not need SSR. I don't. I expect there will be more work to optimize it and eventually it'll be obviously a good i…

It's the other way around: you might not (in fact, probably do not) need React. Start with server-side rendering, and move to React if your application's dynamism demands it. Most applications don't. It's painful to see so many websites building huge, slow, JS-rendered monsters for one or two dynamic elements per page. Unless you are Facebook (and have your JS cached within one hop of every internet POP in the world)…

The difference there is that it's very hard to port a non-JS server-side-rendered site to React if it turns out you do need to. Whereas it's relatively easy to port a React application to additionally do server-side rendering.
Post reply on HN