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

111–120 of 172 posts

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

#111

Post by spicyj »

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.

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

#112

Post by 1_player »

christophilus wrote: post #88
alessioalex wrote: post #86

Earlier quoted context omitted.

If I'm not mistaken Angular 2+ also has this. It's named AOT compilation (ahead of time). Edit: so does Vue if you're using vueify ( https://github.com/vuejs/vue/issues/4272 ).

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…

I'll have a look at Glimmer later, but who executes this bytecode?

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

#113

Post by davidpatrick »

retrac98 wrote: post #13

Yup, the Twitter replies are pretty much what I expected. This tit-for-tat JS pissing contest is so old. Just use what makes sense for your project, there are no silver bullets.

Everyone uses these types of headlines to justify their positions.

The statement was meant to provoke people, and honestly if it wasn’t Netflix nobody would give a damn. Because the real headline is “We chose the wrong tool for the job! Even pros make mistakes”.

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

#114

Post by dean »

1_player wrote: post #112
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…

I'll have a look at Glimmer later, but who executes this bytecode?

> They are instantly executable by a small VM written as a JS library

Guess you have download the VM on initial page load.

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

#115

Post by keda »

1_player wrote: post #112
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…

I'll have a look at Glimmer later, but who executes this bytecode?

glimmer-vm https://github.com/glimmerjs/glimmer-vm

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

#116

Post by pluma »

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?

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

#117

Post by jasonlotito »

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?

What's funny is that your conclusion is incorrect.

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

#118

Post by pluma »

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.

Except "react-renderer" is just React.

As some people who have been paying attention said from day one: other than the component model and unidirectional data flow, what makes React stand out is that it's ultimately a way to describe a UI in terms of functions that output a component tree. Whether you apply that component tree to the browser DOM or use it to generate static markup makes no difference (or to glue together native components as with React Native).

A lot of the more complex features only make sense in an interactive context (i.e. when rendering in the browser) but React is a great choice for server-side rendering too. And unless your initial rendering logic is as complex as the Netflix landing page's and the interaction logic is as trivial, you can just hydrate what the server spits out and go on from there.

The difference is that historically we used one code base to generate the initial markup and another to breathe life into it. With React we can do both with the same code. And in this case Netflix just skips the client-side rendering in favour of a tiny bit of JS (which means they're still using the same language which is still better than the mess we had in the early '00s).

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

#119

Post by ry_ry »

jnbiche wrote: post #110
akerro wrote: post #18

Earlier quoted context omitted.

I just use lynx to browse and block downloading js files by default. I wrote this comment using ed and curl.

Ha, you kids and your fancy lynx browsers. I do just fine with Netcat and typing in the HTTP requests by hand. Works just fine!

I wrote this with a torch and a length of fibre optic cable.

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

#120

Post by atomicUpdate »

samsaccone wrote: post #106
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…

Hi could you post some before and after traces (chrome dev tools recordings) of the site. Performance is nuanced, and the original tweet only helps to put down others (the react team) unfairly. I think the win here is less about react and more about not running as much javascript on the client. I hypothesize that the traces will show this, but it is impossible to know for sure without them :) Thanks in advance!

> the original tweet only helps to put down others (the react team) unfairly.

There was nothing personal or malicious in that slide at all. Do we need a safe space to talk about performance metrics now?

Post reply on HN