Live data from Hacker News

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

twitter.com

161–170 of 172 posts

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

#161

Earlier quoted context omitted.

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…

The idea behind React is pretty cool, that all DOM transformations happen in the template. But that's all it is.

There's no need for a vdom for the most part, template strings and innerHTML are fast enough on their own.

I just find React to be an overly complicated way to achieve its goals.

   var model = { text: '' }

   var component = $( '.component' ).on( 'render', function() {
       $(this).html( `${ model.text }` )
   })

   update( 'text', 'Hello world' )

   function update( key, val ) {
       model[ key ] = val;
       component.trigger( 'render' )
   }
That's React in 8 lines of jQuery. My framework is just a minor extension to this concept.

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

#162

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…

I'm sorry bigmanwalter but you're working on a team of 3 people, not 100+ engineers working in the same codebase.

And you've created your own abstraction beyond "jquery bits for each component".

This is proper vanillaJS engineering, I do the same, it's just not what you're selling here.

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

#163

Earlier quoted context omitted.

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…

The idea behind React is pretty cool, that all DOM transformations happen in the template. But that's all it is. There's no need for a vdom for the most part, template strings and innerHTML are fast enough on their own. I just find React to be an overly complicated way to achieve its goals. var model = { text: '' } var component = $( '.component' ).on( 'render', function() { $(this).html( ` ${ model.text } ` ) }) upd…

> That's React in 8 lines of jQuery

No sir, that doesn't include server side rendering or diff rendering either (meaning changing a bit on the top component would re render all markup, not just what has changed)

Stop trying to over-simplify. The problem being discussed here is not React vs jQuery. It's what we do and the decisions we make as engineers to provide a good experience based on performance which is OUR side of UX.

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

#164
post #144

Earlier quoted context omitted.

What's funny is that your conclusion is incorrect.

It would be much better to say how. Then your comment would be substantive and we would learn something.

True. I was replying to a sarcastic comment in a sarcastic way. Mea culpa.

> Removing an advanced library

They made it clear they didn't remove the library. They still load it later, and still use it.

> from a simple project

They make it clear it's not a simple project. In fact, it's probably one of the more complex pieces of the project.

> increases performance.

No, it increased specific metrics that they cared about.

> Sorry for being sarcastic but don't you also find this too obvious?

Your comment, or their results? Your comment is incorrect based on a single slide and taken out of context. As for the actual reasons, no, they are not obvious at all. Incredibly intelligent people didn't find it obvious, as this was something they clearly didn't see at the beginning, and instead relied on measurements.

Premature optimization and all that.

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

#165

Earlier quoted context omitted.

The idea behind React is pretty cool, that all DOM transformations happen in the template. But that's all it is. There's no need for a vdom for the most part, template strings and innerHTML are fast enough on their own. I just find React to be an overly complicated way to achieve its goals. var model = { text: '' } var component = $( '.component' ).on( 'render', function() { $(this).html( ` ${ model.text } ` ) }) upd…

> That's React in 8 lines of jQuery No sir, that doesn't include server side rendering or diff rendering either (meaning changing a bit on the top component would re render all markup, not just what has changed) Stop trying to over-simplify. The problem being discussed here is not React vs jQuery. It's what we do and the decisions we make as engineers to provide a good experience based on performance which is OUR sid…

I mean, you can use either the of the morphdom or setdom libraries to do the diffing if you don't want to replace all the HTML, but the concept remains the same.

I'm not convinced by arguments such as "when you're a large team it's necessary". Scaling teams has more to do with project structure than what rendering library you use.

Likewise, it's much easier to tweak performance when you aren't depending on a monolith like React or Angular.

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

#166

Earlier quoted context omitted.

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…

I'm sorry bigmanwalter but you're working on a team of 3 people, not 100+ engineers working in the same codebase. And you've created your own abstraction beyond "jquery bits for each component". This is proper vanillaJS engineering, I do the same, it's just not what you're selling here.

Well of course I've created my own abstraction... that's what programming is.

I prefer to keep my abstractions simple and light, and preferably built using lower level libraries. If I can build a powerful component system in 150 lines of jQuery (and it would be barely more in vanilla js), I much rather do that than than import a 30kb + library.

There are plenty of 4kb react alternatives to choose from. Most with vastly simpler APIs. Choo.js or Mithril come to mind :)

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

#167

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…

Anyone thinking on betting on Ember, or Glimmer.

Word of advice / wisdom from having built multiple platforms / sites with it:

Don't.

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

#168
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…

Please make the search textbox always visible. Most of the times I go to Netflix.com is to see if it has the movie I want to see. (I live in Sweden, Netflix is pretty small here)

And going to the front page of Netflix, clicking the Search icon is not a pretty experience. What happens next is a chuggy chuggy animation of the textbox gliding out, and typing in it is a disaster of input lag.

I bet you fire an event for each key I press while in there? Perhaps wait with that until the rest of the page has loaded?

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

#169

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.

I believe my case was pretty clearly articulated as are some of the other comments on a thumbnail sketch of the tradeoff comparison we have and continue to do. I'm sorry you believe the worst in this community.

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

#170
post #146

Earlier quoted context omitted.

Let’s say you think it’s not React or you have time to improve React to solve that problem: wouldn’t having some data help test that assertion and make changes?

We have the data: they removed React and performance increased by 50%. Why should any more work be put into keeping React or improving it if their solution of removing it entirely already works?

Well, for one, cause they did /not/ remove it entirely: They use it on the server.

It doesn't "work", it's a hack.

50% isn't data. It's a claim without evidence. The evidence in this case may help fix React.

Post reply on HN