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

151–160 of 172 posts

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

#151

Post by christophilus »

irrational wrote: post #139
christophilus wrote: post #88

Earlier quoted context omitted.

It's not the same, though. Those are compiling textual templates into executable JavaScript. React/Preact do this automatically, too. What Glimmer does is it converts your views into bytecode (not JavaScript) which can be streamed and run without a JavaScript compilation / parsing phase in the browser. Vue, React, and Angular views all ultimately are translated into JavaScript which has to be compiled / parsed in eac…

Is it more similar to Vue server-side rendering ( https://vuejs.org/v2/guide/ssr.html )? Or are Glimmer and server-side rendering two different beasts?

Two different beasts.

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

#152

Post by bigmanwalter »

always_good wrote: post #135
bigmanwalter wrote: post #109

Earlier quoted context omitted.

That's completely untrue. I've built both SPA and traditional fullstack applications similar to the mentioned architecture (although I prefer Python over PHP). Fullstack is a fraction of the complexity, with much more power. You can even use a simple library like PJAX to get all the same speed boosts an SPA offers without introducing any of the additional complexity. To be honest, I don't see what React offers beyond…

I have a hard time believing that you built a non-trivial SPA that you consider easy to maintain without an abstraction beyond jQuery. There's just inherent complexity in software, so it's like suggesting that you built an application without ever writing code outside of main() (functions are for hipsters).

I mean, you're welcome to have a look at it https://github.com/IEMLdev/Intlekt-editor

An example of how I put together a component is here https://github.com/IEMLdev/Intlekt-editor/blob/master/src/sc...

- My "view" function takes a template string and replaces the node's content whenever "render" is triggered.

- I create a "model" object which triggers a "render" event anytime it changes. You can also give the model object methods which act as Redux-style reducers.

- The controller method is a shorthand for registering multiple jQuery events at once.

That's pretty much all you need for a complex app. It's the entire React-Redux architecture à la jQuery + ES6.

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

#153

Post by bigmanwalter »

cname wrote: post #141
bigmanwalter wrote: post #109

Earlier quoted context omitted.

That's completely untrue. I've built both SPA and traditional fullstack applications similar to the mentioned architecture (although I prefer Python over PHP). Fullstack is a fraction of the complexity, with much more power. You can even use a simple library like PJAX to get all the same speed boosts an SPA offers without introducing any of the additional complexity. To be honest, I don't see what React offers beyond…

> I don't see what React offers... It sounds like the sites you've worked on didn't have enough UI complexity to make something like React necessary. Even for a relatively simple admin or dashboard type site, using a more modern framework/library will make it much easier to build and maintain.

I use a modern batteries-included fullstack framework. It's incredibly easy to maintain :)

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

#154

Post by ukulele »

wolco wrote: post #92
ukulele wrote: post #78

Earlier quoted context omitted.

I'm also a big fan of Vue, but why would it be different in this instance?

Quicker load time but a landing page can be more static. No framework needed.

I meant why would it be different than React.

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

#155

Post by drdiablo »

clarle wrote: post #52

Hey, I work on the team at Netflix that gave the talk on React in the signup flow in the tweet. The full talks are available here if people want to watch them: https://www.youtube.com/watch?v=V8oTJ8OZ5S0&t=11m30s Thought I'd also provide some more context on some common questions that people have asked. ### Why are you using React to render a landing page? The Netflix landing page is a lot more dynamic than most peop…

Thanks for taking the time to answer everyone's questions!

Do you simply use Nodejs to do the SSR? I've seen some complaints about the difficulty of scaling node to run well in a cluster, and about security things. Have you had to deal with that?

I'd honestly love to see what you did there. People use Java for the reason that all of those questions have decent answers by now.

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

#156

Post by CyberDildonics »

christophilus wrote: post #107
CyberDildonics wrote: post #93

Earlier quoted context omitted.

Why use binary VM instructions with a VM written in JS instead of just straight binary data? Why does it even need to be instructions in the first place?

It needs to be instructions because the views aren't static. They are reactive. So some of the content is static, some might change due to user interaction. The VM understands this fundamentally and optimizes for that.

I'm not clear on where the logic is needed. Even if there are cells or boxes that need to be a percentage of their parent and/or have min and max sizes etc, that can still just be binary data.

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

#157

Post by ravenstine »

DougBTX wrote: post #21
_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.

Why else would we have stuff like this? https://github.com/Izzimach/react-three

As if ThreeJS is too hard or cumbersome without React.

Or this: https://github.com/FormidableLabs/react-game-kit

Or this: https://www.npmjs.com/package/react-audio (a relatively unknown library, but it's surprising how often projects will import packages like this)

I generally do what I can to avoid software snobbery, but it's examples like those that really cause me to scratch my head and exclaim "Why?"

React makes sense when you actually have a DOM to deal with, but as soon as you start trying to write something that goes beyond that model, well, I really don't get you. ("you" being rhetorical)

Generally, though, I think a lot of junior programmers or those new to React get very enthusiastic about it and try to solve whatever problem they can with a tool that works well for them, and that does speak quite a bit to how good React is. In general, I would avoid using React for things it was not designed for.

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

#158

Post by error54 »

spicyj wrote: post #111
clarle wrote: post #52

Hey, I work on the team at Netflix that gave the talk on React in the signup flow in the tweet. The full talks are available here if people want to watch them: https://www.youtube.com/watch?v=V8oTJ8OZ5S0&t=11m30s Thought I'd also provide some more context on some common questions that people have asked. ### Why are you using React to render a landing page? The Netflix landing page is a lot more dynamic than most peop…

I work on React. We’d love to hear from your team sometimes and collaborate on this sort of thing. We’re solving many of the same problems but I rarely hear from Netflix engineers except at talks when announcing they’re avoiding React or have forked it, often for reasons we weren’t even aware of.

Hey spicyj!

I'd love to sit and talk React with you and your team. We're always particularly interested in performance optimizations so maybe we can swap some knowledge.

Not aware of any team that is actively avoiding React but we're a fairly prolific bunch when it comes to public speaking and knowledge sharing so perhaps I missed some announcement from another UI team. A few of my colleagues will be speaking at the SFHTML5 meetup[1] in a few weeks if you'd like to come hang out and talk shop or feel free to drop me a line at jem@netflix.com :).

1 - https://www.meetup.com/sfhtml5/events/244074642/

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

#159

Post by error54 »

pluma wrote: post #116
clarle wrote: post #52

Hey, I work on the team at Netflix that gave the talk on React in the signup flow in the tweet. The full talks are available here if people want to watch them: https://www.youtube.com/watch?v=V8oTJ8OZ5S0&t=11m30s Thought I'd also provide some more context on some common questions that people have asked. ### Why are you using React to render a landing page? The Netflix landing page is a lot more dynamic than most peop…

So in other words: the main reason removing the React code in the frontend in this case gave such an immense performance benefit is that the logic used to compute the rendered UI is significantly more complex than the logic necessary to make that UI interactive. It's not React that's slow, it's the logic needed to render the page?

That's pretty close. For our use case (and many others), the biggest culprit for increased TTI is the sheer size of the JavaScript payload and the time the browser takes to parse the whole bundle[1]. We still use React and other libraries on the server to generate the HTML but rather than sending all that JS down, Tony worked out exactly which client interactions still needed JS and wrote those in plain JS which resulted in a big TTI win as the browser simply had less data to parse.

1- https://www.youtube.com/watch?time_continue=1297&v=M1qm-AWWu...

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

#160

Post by always_good »

bigmanwalter wrote: post #152
always_good wrote: post #135

Earlier quoted context omitted.

I have a hard time believing that you built a non-trivial SPA that you consider easy to maintain without an abstraction beyond jQuery. There's just inherent complexity in software, so it's like suggesting that you built an application without ever writing code outside of main() (functions are for hipsters).

I mean, you're welcome to have a look at it https://github.com/IEMLdev/Intlekt-editor An example of how I put together a component is here https://github.com/IEMLdev/Intlekt-editor/blob/master/src/sc... - My "view" function takes a template string and replaces the node's content whenever "render" is triggered. - I create a "model" object which triggers a "render" event anytime it changes. You can also give the model…

That's quite a complicated, embedded framework.

If that's "just jQuery", then React is "just ES6". I don't understand the distinction. Every abstraction is built on the layer below. You just rolled your own bespoke one instead of using one that already existed.

> I don't see what React offers beyond what you get with a templating language like Handlebars, and a few lines of jQuery for initializing components.

You say that like that's all your framework does, but I see more than that.

Seems you're mistaking different trade-offs for objective improvements, something that almost rarely exists in software despite what you read in HN comments.

Post reply on HN