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

101–110 of 134 posts

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

#101

Post by always_good »

lmm wrote: post #100
timr wrote: post #73

Earlier quoted context omitted.

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.

The other difference is that I'm having a hard time imagining a scenario where someone is getting blindsided by "damn, it should've been a SPA after all!"

I'd be wary of all of the technical decisions that were made if the decision-maker knew so little about the requirements that they couldn't even call that shot correctly.

Of course, on a long enough time scale, all bets are off.

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

#102

Post by lmm »

always_good wrote: post #101
lmm wrote: post #100

Earlier quoted context omitted.

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.

The other difference is that I'm having a hard time imagining a scenario where someone is getting blindsided by "damn, it should've been a SPA after all!" I'd be wary of all of the technical decisions that were made if the decision-maker knew so little about the requirements that they couldn't even call that shot correctly. Of course, on a long enough time scale, all bets are off.

> The other difference is that I'm having a hard time imagining a scenario where someone is getting blindsided by "damn, it should've been a SPA after all!"

I've seen it happen more than once. Start with what looks like a straightforward form flow, seems like it should be fine in rails or whatever. Then it turns out some fields depend on other fields, so you've got to dynamically show/hide parts when other parts are set. And doing a server roundtrip, even AJAXey, is just too slow. So you put a bit of client-side Javascript to handle that. And then as the product evolves the interrelations between the form elements become more and more complex and businessey, and you have more and more logic split or duplicated between backend and frontend.

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

#103

Post by rsynnott »

qaq wrote: post #52
rsynnott wrote: post #47

Earlier quoted context omitted.

Assuming that your actual use case is rendering one small HTML table, yes. It probably isn’t, though.

OK lets assume it's 30x that do you really think that 300/month for SSR would be an issue for a site serving 400 mil sessions per month?

Given the latencies shown in the article, if it's 30x that it'd probably take a few hundred ms to render. I'd view that as unacceptably slow; your milage may vary. Also, I suspect 30x that is optimistic for a complex site; it is a single small table.

400m sessions a month doesn't really sound like that much...

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

#104

Post by anatoli »

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.

No worries. The reader has as much responsibility to question the material they're consuming :)

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

#105

Post by dustingetz »

dfee wrote: post #81
setr wrote: post #61

Earlier quoted context omitted.

Why in the world would you take over scrolling like that Is this how you get your kicks?

I thought, “can’t be that bad”. The clicked and it was unusable on my phone. That is bad.

What is the scroll bug exactly, or are you referring to the perf problems?

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

#106

Post by styfle »

MatthewPhillips wrote: post #35

Note that React doesn't do streaming HTML in the traditional sense. You can't send out initial HTML while you wait on an API response, for example. Instead only the serializer is streaming. Your app renders to a VNode synchronously and then the serializer traverses the VNode, synchronously, and streams the strings out as it goes. This is why streaming is only a little bit better in these numbers. If/when React gets r…

I believe you can stream the while still waiting for any react components to render like so:

https://github.com/styfle/react-server-example-tsx/blob/4586...

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

#107

Post by styfle »

lucaspiller wrote: post #93
spinlock wrote: post #70

Earlier quoted context omitted.

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 Rea…

> then when React has loaded, replace it with a React component

What you described is basically `hydrate` which is how to enable React event handlers like onClick after a server-side render.

https://github.com/styfle/react-server-example-tsx/blob/4586...

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

#108

Post by [deleted] »

mottomotto wrote: post #91
timr wrote: post #87

Earlier quoted context omitted.

"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 me…

[deleted]

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

#109

Post by timr »

mottomotto wrote: post #91
timr wrote: post #87

Earlier quoted context omitted.

"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 me…

"I've got low latency, I have client-side URL routing, I have no need for progressive enhancement"

Again, maybe you're in the 5% of "web application" users that are not actually web applications, but rather, "browser apps that download some data once in a while". If so, great. Most people aren't in that group.

Also, just to clear this up: client side URL routing is not URL routing. It's an ugly hack to make up for the fact that you can't use URLs for their stated purpose. It's honestly sad that we've wandered so far from the norms of the web that URLs have lost their meaning.

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

#110

Post by mottomotto »

timr wrote: post #109
mottomotto wrote: post #91

Earlier quoted context omitted.

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 me…

"I've got low latency, I have client-side URL routing, I have no need for progressive enhancement" Again, maybe you're in the 5% of "web application" users that are not actually web applications, but rather, "browser apps that download some data once in a while". If so, great. Most people aren't in that group. Also, just to clear this up: client side URL routing is not URL routing. It's an ugly hack to make up for th…

It's not an ugly hack at all. It works well, the browser history works properly and the interaction is just as if the pages were being fetched from the server. At any point in time, the user can do a hard reload and the page will rerender as it did before. The URLs are the same as if I was doing server-side rendering.

So I would ask you at this point to turn this all around. Look at it from my perspective. I've been doing fullstack for more than a decade (professionally, hobbyist for twice as long) so I've done plenty of server-side rendering in frameworks like Ruby on Rails, ASP.net MVC, etc. I've contributed (as lead) to open source gems that have over 800k downloads. So I have invested a lot of time into the server-side.

But today, with client-side, there is a huge simplicity factor. You can only get to it after wading through the turbulent waters of "flavor of the week" client-side projects and noise. But when you do get through that and identify your pillars to build on, this is what you have:

* all of your complexity is on the client-side for web

* you can make a simple fairly clean REST or GraphQL backend that will work with multiple clients (web, mobile, etc)

* for at least REST, you no longer really need things like an ORM on the server-side as all of the endpoints are simple and basically fetching a single data type (I use SQL with PostgreSQL so I would say a table here but it depends on implementation)

* HTTP/2 reduces the cost of small requests so complex things like GraphQL aren't really necessary -- you can stay with REST without a penalty

Is there complexity? Is it different? Does it challenge the conceptions of those used to fullstack? Yes. But there is real value and simplicity here too that you might find if you're willing to put aside your hard and fast rules and try something new.

Post reply on HN