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

Netflix: Removing client-side React.js improved performance by 50%

twitter.com

Post reply on HN
Print view View original

21–30 of 172 posts

Re: Netflix: Removing client-side React.js improved performance by 50%

#21

Post by DougBTX »

_reaction_ wrote: post #15

My experience with React has not been good. A gullible manager bought into "react everywhere" hype, flew in consultants for training and then proceeded to have a dozen pages on the website written in React. It's important to note that all but one was either completely static or a simple form with less than 5 fields. This project did not go well. It took months to develop, has 0 test coverage, numerous bugs and doesn'…

> A manager bought into "react everywhere" hype

...that actually exists? Seems crazy.

> My experience with React has not been good.

Certainly from your story it sounds like you had a bad experience, but it seems to be in the "had a bad experience with a hammer, terrible for hammering in screws" type of experience.

Re: Netflix: Removing client-side React.js improved performance by 50%

#22

Post by buchanaf »

danvasquez29 wrote: post #14
positivecomment wrote: post #10

Today we learned: Removing an advanced library from a simple project increases performance. Sorry for being sarcastic but don't you also find this too obvious?

I think it's the 50% part that we're meant to pay attention to. For me that's a pretty drastic, "why would you ever put this on the client side now that you know this" kind of thing.

The caveat is that this is in reference to a _landing page_ only. If you try to write an advanced application with vanilla.js and you aren't some Javascript guru, then you are going to really hate yourself later on -- I guarantee it.

Also, that 50% is only measuring the time to interactive on what I imagine is the first page visit. After everything becomes cached, I would think that the the benefit is dramatically lower.

Re: Netflix: Removing client-side React.js improved performance by 50%

#23

Post by romanovcode »

megaman22 wrote: post #19
romanovcode wrote: post #9

Earlier quoted context omitted.

So basically they write React in front-end, then use react-renderer to generate static HTML and then serve it from back-end? Seems like with this speed JS frameworks are going full-circle back to back-end rendering soon enough.

Everything is a circle in web development. It appears to take about five to ten years for developer personnel to turn over close to 100%. And so the cycle continues, with old ideas dusted off or rediscovered, the original flaws in them rediscovered, the reaction to those flaws, traveling well-trodden paths, then the reaction to the reaction, "best practices" shaking out, an explosion of complexity, and then someone b…

Actually that is exactly what I thought when they introduced RazorPages as well.

I really like .NET Core but this RazorPages is just single worst "improvement" for the .NET Core platform.

I even remember watching the presentation on BUILD conference and nobody applauded at this "feature" when they graciously introduced it and you could feel the cringe. Scott even had to say "Isn't this awesome!?? Come on!".

No, Scott, it's not awesome. It's going backwards.

Re: Netflix: Removing client-side React.js improved performance by 50%

#24

Post by jinfiesto »

_reaction_ wrote: post #15

My experience with React has not been good. A gullible manager bought into "react everywhere" hype, flew in consultants for training and then proceeded to have a dozen pages on the website written in React. It's important to note that all but one was either completely static or a simple form with less than 5 fields. This project did not go well. It took months to develop, has 0 test coverage, numerous bugs and doesn'…

Don't mean to be rude, and it certainly seems like React was overkill for your project, but 6 months to generate a react site like you're describing seems like the problem might not have been react. Maybe it was engineering, or maybe it was management, but cranking out a react app that's "completely static or a simple form with less than 5 fields" is something one developer should be able to do in a day or two after reading a basic react tutorial (assuming there are design guidelines)...

Which is not to say I'm not sympathetic to bandwagoning having a negative impact on engineering teams. Just that in this case, I find it hard to believe that react specifically was the problem.

Re: Netflix: Removing client-side React.js improved performance by 50%

#25

Post by jinfiesto »

romanovcode wrote: post #9
tyingq wrote: post #5

Earlier quoted context omitted.

In the talk they say they are still using react server side to make this mostly static page. I suppose with some cache in front of it though.

So basically they write React in front-end, then use react-renderer to generate static HTML and then serve it from back-end? Seems like with this speed JS frameworks are going full-circle back to back-end rendering soon enough.

This is largely what we do, except with Angular. We generate the angular dynamically server side and then serve it up on a per-user basis.

Re: Netflix: Removing client-side React.js improved performance by 50%

#27

Post by falcolas »

brokentone wrote: post #20
danvasquez29 wrote: post #14

Earlier quoted context omitted.

I think it's the 50% part that we're meant to pay attention to. For me that's a pretty drastic, "why would you ever put this on the client side now that you know this" kind of thing.

Because it provides a robust, consistent, isomorphic framework which many people have decided that certain benefits (for us common tooling, maintenance, consistent implementation across the org, write once run twice isomorphism) outweigh the costs (interactable time, download size, etc). Everyone has to make their own choices, but this news was not surprising and did not change our opinion.

Playing devil's advocate for a moment:

So, the developer experience trumps the user experience, in an industry where fractions of a second of load time can cost a company customers and conversions?

Re: Netflix: Removing client-side React.js improved performance by 50%

#29

Post by mattdeboard »

falcolas wrote: post #27
brokentone wrote: post #20

Earlier quoted context omitted.

Because it provides a robust, consistent, isomorphic framework which many people have decided that certain benefits (for us common tooling, maintenance, consistent implementation across the org, write once run twice isomorphism) outweigh the costs (interactable time, download size, etc). Everyone has to make their own choices, but this news was not surprising and did not change our opinion.

Playing devil's advocate for a moment: So, the developer experience trumps the user experience, in an industry where fractions of a second of load time can cost a company customers and conversions?

Calm down. This is for a single, static landing page.

Re: Netflix: Removing client-side React.js improved performance by 50%

#30

Post by cynicalreason »

falcolas wrote: post #27
brokentone wrote: post #20

Earlier quoted context omitted.

Because it provides a robust, consistent, isomorphic framework which many people have decided that certain benefits (for us common tooling, maintenance, consistent implementation across the org, write once run twice isomorphism) outweigh the costs (interactable time, download size, etc). Everyone has to make their own choices, but this news was not surprising and did not change our opinion.

Playing devil's advocate for a moment: So, the developer experience trumps the user experience, in an industry where fractions of a second of load time can cost a company customers and conversions?

'premature optimization', build it first, optimize later, react helps a lot with the first part
Post reply on HN