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

71–80 of 172 posts

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

#71

Post by juandazapata »

zpr wrote: post #61
christophilus wrote: post #31

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…

Glimmer itself is made by Ember?

Yes, the ember core team is behind Glimmer you can use it today in Ember.

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

#72

Post by grandalf »

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?

You are correct. This is such an obvious, simple thing that anyone with a small bit of experience optimizing a static website for render completion would understand.

React is designed to allow a server-side render and an async load of the js library to allow it to be used in this kind of scenario without impacting perceived load time or "time to interaction".

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

#73

Post by techaddict009 »

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.

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

#74

Post by grandalf »

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.

No this is the wrong conclusion to draw.

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

#75

Post by positivecomment »

nindalf wrote: post #60
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.

I don't know why you'd use such heavy duty applications for such a simple use case. I merely use a butterfly to induce cosmic rays to flip the bits of memory needed to send a http request.

A butterfly is way more complex than React.js.

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

#76

Post by jordache »

jd3 wrote: post #62
jordache wrote: post #58

Earlier quoted context omitted.

Netflix website is a simple project!? Wha?

it displays information about videos that are stored on a server - it's not that complicated.

oh yeah.. some jquery or vanilla JS would be fine. no need to abstract a workflow or anything.. it's literally like a scrolling marquee.. a couple of guys on it should be sufficient.. No need for Git either.

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

#77

Post by JoBrad »

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

Default choices on that page show the following file size:

  Final size: 0 bytes uncompressed, 25 bytes gzipped.

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

#79

Post by grandalf »

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?

Not at all. The objective for a landing page is very different from all the other pages.

Landing Page: Make it load instantly so that a new user clicking on it doesn't get frustrated and close the window before it's ready to go. This is typically a static page. Note the tiny and heavily optimized google.com

Other Pages: It's sometimes necessary to load larger js libs gradually, but generally once they are loaded the browser cache makes their size a non-issue.

In summary: It's worthwhile to pay the cost of libraries, but that cost should not be paid by visitors to the landing page, and if the cost is high it might be necessary to load them in phases to preserve a good UX.

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

#80

Post by clarle »

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 work on the team at Netflix that gave this talk.

Thought I'd share a bit more context on the reasons that we did this beyond a picture from a tweet:

https://news.ycombinator.com/item?id=15568305

Let me know if you have any questions!

Post reply on HN