Live data from Hacker News

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

twitter.com

101–110 of 172 posts

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

#101

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.

> and did not change our opinion.

If this comment section is any clue, clearly it's not going to change a React programmers opinion because they completely loose their shit if you mention a flaw in React.

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

#102

Earlier quoted context omitted.

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

"'Premature optimization is the root of all evil' is the root of evil"

https://medium.com/@okaleniuk/premature-optimization-is-the-...

http://ubiquity.acm.org/article.cfm?id=1513451

http://www.joshbarczak.com/blog/?p=580

http://scottdorman.github.io/2009/08/28/premature-optimizati...

It's basically an excuse to not think about the performance or implementation of your entire product until the end and then, when you use a profiler and chop away "10%" here and "20%" there, you still end up with a slow-as-piss program with every function taking less than 1% total time. Then what do you do?

Oh yeah, what you should have done in the first place. _Think_ about how your program actually functions so you can remove all of the insane systemic, architecture decisions you made that all bleed a fixed amount of time every single function call. That's the difference between an engineer, and script kid. If you're not reasoning about _the entire platform_ (all the way down to the cache lines), you're not engineering. You can abstract all you want, but those abstractions don't magically prevent the underlying hardware and architectural decisions from affecting the product. Abstractions tools (read: approximations!) for high-level reasoning. They're not magic "you don't have to think [about low level implementation]" spells.

Actual experts keep trying to warn you guys about abusing that quote, but nobody apparently ever listens. Stop quoting it like a bible verse, because just like bible verses, everyone forgets the entire context and just uses it like a bloody bumper-sticker slogan.

In the words of Saul Williams: "You have wandered too far from the original source, and are emitting a lesser signal."

The full Donald Knuth quote:

>The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.

That quote sounds much less like a law handed down by God, and more a guideline from experience, no?

Optimizing the wrong things (things that get thrown away when you change your program as you work toward your goal) ends up wasting time. But just because that was applicable _in the 70's_ doesn't mean modern programmers have the same mentality of "optimize optimize optimize." Modern programmers have the opposite. They're so afraid of having to learn how cachelines work, they use that quote to prevent having to do any optimization (or understanding of architectural layout tradeoffs). I can't count how many programmers I've met that hear "cache" and their eyes glaze over like it's some magical, incalculable thing.

Watch a lecture from Mike Acton, where on consoles, they don't have the luxury of writing poorly written, un-optimized code. They _do_ have to understand the entire platform to ship a competitive title. Because any optimizations they do, for a fixed platform, means they can pump out a better experience with those extra CPU cycles. An experience that elevates them above their competitors.

https://www.youtube.com/watch?v=rX0ItVEVjHc

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

#103
post #94
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…

It is quite telling that you give the example of the component which has "one or two checkboxes on the UI" that "has some of the most complicated logic in the codebase".

I can't quite tell what you're implying here... but this makes total sense to me.

Every country has different regulations, and therefore would require different wording and agreements as a Terms of Use. Anyone that has worked at a multi-national company understands this is just The Way It Is.

At Nike there is a ton of logic on a per-country basis. For example, they might own the copyright of the word "FlyKnit" in most countries, but in Italy they don't and get fined if it's ever misused. There's a TON of development work that caters to legal / regulation problems like this.

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

#104
post #53

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

That site has been around a while, and is definitely a joke ;) No matter what you check off to include in the library, the generated file is 0 bytes.

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

#105
post #77
post #53

Earlier quoted context omitted.

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

Default choices on that page show the following file size: Final size: 0 bytes uncompressed, 25 bytes gzipped.

Gzip format has: 10 byte header, 8 byte footer, optional additional headers, and DEFLATE compressed content.

So, yeah, +25 bytes seems reasonable.

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

#106
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!

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

#107

I was at the All Things Open conference this week, and Yehuda Katz gave a talk on Glimmerjs[0]. It was enlightening. The size of your front-end application is generally dominated by view code. So, they precompile views into a super simple set of binary VM instructions (making your views very compact). These views don't go through the JS compile / parse phase on the client (saving hundreds of ms, up to seconds on slow…

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.

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

#108

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.

> and did not change our opinion. If this comment section is any clue, clearly it's not going to change a React programmers opinion because they completely loose their shit if you mention a flaw in React.

This isn’t a flaw in React, this is using the wrong tool for the wrong job. React is great, but it doesn’t solve ALL problems.

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

#109

We learned this hard way :P We avoid fancy tools as much as possible and use basics as much as possible. Laravel + Bootstrap + JQuery + MySQL works pretty well then this modern stuff. Easy to implement, deploy and manage. P.S. Use knife which you really need. Try to use simple knife as much as possible.

> 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 what you get with a templating language like Handlebars, and a few lines of jQuery for initializing components.

This is, of course, for database heavy applications where each action requires the backend. If you're building a game, or an app that's mostly offline, SPA can be helpful.

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

#110
post #18

Earlier quoted context omitted.

Go next level: Remove the whole browser and make a native application - gain even more performance!

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!
Post reply on HN