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

121–130 of 134 posts

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

#121

Post by mottomotto »

timr wrote: post #120
mottomotto wrote: post #110

Earlier quoted context omitted.

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…

"It's not an ugly hack at all. It works well" URLs are addresses of resources on the internet. They're parsed by your browser to request resources on another server. If you've rewritten this functionality in JavaScript to support storing application state in your single-page application, it may "work well" but it is, in fact, a hack. If you've done this to support storing application state in your web application tha…

I haven't written this functionality in, it's a browser API:

https://developer.mozilla.org/en-US/docs/Web/API/History_API

https://html.spec.whatwg.org/multipage/history.html#history

None of these arguments are for a specific stack. React has little to do with any of this. We're talking about underlying technologies that enable the web to be used as a platform for application development.

My point about an ORM is that your API becomes so simple you don't require a lot of complexity that is required with server-side joins of data in order to render a view. That is gone. No need. I'm giving you examples assuming you can extrapolate them to a bigger picture.

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

#122

Post by Can_Not »

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.

This is something a lot of people just don't get. And with react's serverside render, you don't get a trashy 2010-era SPA, you have an SPA that is also an MPA. It's literally the best of both worlds with porting your redux to reactnative for Android/iOs just around the corner.

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

#123

Post by mottomotto »

shams93 wrote: post #95
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.

That really is dependent on use case though. In my current project, I want the most up to date data possible so no caching. In reality, it is cached locally in the browser state and soon, I will be pushing data to update that browser state (based on other users activity in the same tenancy).

I think generalizing to "we should be building progressive web apps" is harmful. You should do what is appropriate for your use case.

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

#124

Post by dustingetz »

dfee wrote: post #117
dustingetz wrote: post #105

Earlier quoted context omitted.

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

No, I opened it on my iPhone X, and regular scrolling (moving my finger up / down the screen) doesn't move the webpage. Instead, I have to try and click the scrollbar on the right hand side (on my iPhone!) and then move the scroller in the opposite direction as I'd swipe.

wow, thanks

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

#125

Post by moogie »

mottomotto wrote: post #123
shams93 wrote: post #95

Earlier quoted context omitted.

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.

That really is dependent on use case though. In my current project, I want the most up to date data possible so no caching. In reality, it is cached locally in the browser state and soon, I will be pushing data to update that browser state (based on other users activity in the same tenancy). I think generalizing to "we should be building progressive web apps" is harmful. You should do what is appropriate for your use…

> I want the most up to date data possible so no caching

This seriously doesn't mean "no caching" and shows a real lack of understanding about caching.

You state that people should so what is appropriate for use case, though your other comments here go completely against that and are cargo cultist in the extreme. I think perhaps, when you say "should do what is appropriate for your use case" you actually just mean "what I think you should do".

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

#126

Post by mottomotto »

moogie wrote: post #125
mottomotto wrote: post #123

Earlier quoted context omitted.

That really is dependent on use case though. In my current project, I want the most up to date data possible so no caching. In reality, it is cached locally in the browser state and soon, I will be pushing data to update that browser state (based on other users activity in the same tenancy). I think generalizing to "we should be building progressive web apps" is harmful. You should do what is appropriate for your use…

> I want the most up to date data possible so no caching This seriously doesn't mean "no caching" and shows a real lack of understanding about caching. You state that people should so what is appropriate for use case, though your other comments here go completely against that and are cargo cultist in the extreme. I think perhaps, when you say "should do what is appropriate for your use case" you actually just mean "w…

It is not the kind of caching that the post I'm replying to is advocating ("the entire app can live offline and even cache data in local storage"). I mentioned the caching I am doing to point out things aren't so simple. I do mean quite literally that none of my API HTTP responses have a caching header (assets are coming from CDN with very long cache life).

It might be more fruitful to try to explain why I go against that instead of simply saying I do without a rational argument that can be responded to. If anything, the thread pretty clearly revealed someone is extremely biased to server-side web frameworks and is unaware of the progression of client-side web APIs.

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

#128

Post by setr »

dustingetz wrote: post #105
dfee wrote: post #81

Earlier quoted context omitted.

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?

On iphone sc chrome browser, what they've apparently done is completely reimplemented scrolling;

the website has its own scrollbar, on top of which chrome renders its own, and the site seems to be scrolling in place of the browser, as the "smooth-scrolling" behavior is entirely gone, as well as other little things like scrolling past the end of the page and being bumped back up

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

#129

Post by MatthewPhillips »

styfle wrote: post #106
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...

Of course, you can stream parts of your page that you don't use React. That should be obvious. :)

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

#130

Post by nathan_long »

scyber wrote: post #32
nathan_long wrote: post #4

Earlier quoted context omitted.

Sure, but every user has to do that initial page load. If all initial page loads are slow and expensive, it affects the user experience and costs money. Also, if you start getting requests faster than you can do the initial render, each subsequent user has to wait in line longer than the one before. Your server-side framework won't even show you how long people waited for a TCP connection.

If the Server rendered page is not user specific and is generic for all users then it can be cached and served quickly. Then only potentially one user would experience a slowdown and you can serve much faster. Of course then you get into the fun of cache management and invalidation.

Elixir Phoenix has a game-changing approach here because of how it compiles templates. Effectively, the static part is always cached (until the template changes), but the dynamic part is never cached. Nothing to manage.

See http://nathanmlong.com/2016/11/elixir-and-io-lists-part-2-io... for explanation.

Post reply on HN