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

131–140 of 172 posts

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

#131

Post by aith »

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…

In the talk you say that you reduced JS and therefore lowered TTI and saw more clicks on the signup button. Is it possible that you are just _tracking_ more clicks, but the total is the same?

Does it really matter how much JS there is if it's loaded after HTML and the user can already move to the sign up step without it?

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

#132

Post by devrandomguy »

throwaway2016a wrote: post #7

Sounds like form the comments they still use React they just defer loading it until after the page is otherwise usable. I think this is a fairly common use case for server-side rendering in React and I wonder how much of this improvement they would have seen just by SSRing the page and putting the React scripts at the end instead of the header (or using defer). This is the strategy I use with any React marketing type…

Yep, and personalization and A/B testing can be accommodated with query params. By whitelisting those AB params in the caching layers, you can mostly prevent a performance difference between A and B, something that may have messed up our results with a 3rd party AB testing service.

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

#134

Post by devrandomguy »

_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'…

It reflects poorly on us that this is being downvoted. The parent shared a simple cautionary tale without baiting or flaming or anything like that. It is a good thing, to be aware of the worst case scenario; IME, projects that fail badly do so mainly for people-reasons / org-reasons, just like this.

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

#135

Post by always_good »

bigmanwalter wrote: post #109
maxhallinan wrote: post #85

Earlier quoted context omitted.

> Laravel + Bootstrap + JQuery + MySQL works pretty well then this modern stuff. It's interesting to remember that Facebook started out as a PHP application. I imagine that Facebook's original tech stack closely resembled the stack you're recommending. And scaling that stack is what led to the creation of React. If you choose to build a rich user interface (like Facebook or Netflix) on top of that stack, you will lik…

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).

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

#136

Post by nerpderp83 »

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.

hbar is no longer Planck's Constant but the speed a which a metacircular hypecycle can JIT itself on your runtime.

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

#137

Post by always_good »

devrandomguy wrote: post #134
_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'…

It reflects poorly on us that this is being downvoted. The parent shared a simple cautionary tale without baiting or flaming or anything like that. It is a good thing, to be aware of the worst case scenario; IME, projects that fail badly do so mainly for people-reasons / org-reasons, just like this.

It doesn't reflect poorly on anybody beyond said company that took six months to build a with five s which was clearly blighted by major issues regardless of which technology they chose for their .

What's interesting is that, despite regurgitating the writing on the wall, OP still blames a JavaScript framework.

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

#138

Post by Can_Not »

dontlikeitupem wrote: post #126
christophilus wrote: post #83

Earlier quoted context omitted.

If you can get all three of these-- good performance, simple application code, and a rich UI experience-- then yes, it's a win.

If you can get all three of these -- overly complicated bloated stack, NIH compliant newness driven development, and yet another crappy poor UI experience -- then no, it's a loss.

Honestly you're just making up non-genuine complaints and criticism in bad faith.

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

#139

Post by irrational »

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…

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?

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

#140

Post by irrational »

cptaj wrote: post #53
buchanaf wrote: post #22

Earlier quoted context omitted.

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

FYI, vanilla.js is a thing now. Some asshole made it a thing. http://vanilla-js.com

Dude, it's a joke. Lighten up.
Post reply on HN