Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Netflix Likes React

techblog.netflix.com

Post reply on HN
Print view View original

41–50 of 60 posts

Re: Netflix Likes React

#41

Post by EGreg »

svachalek wrote: post #39
EGreg wrote: post #31

Can someone explain to me why virtual DOM is faster than DOM implementations of browsers?

Actually changing the DOM has a lot of implications. Recalculating CSS, layout, possible side effects that generate events, repainting, etc, etc. It's a lot of work to go through for an intermediate state that may not even last long enough to be visible to the user. Buffering and batching those changes can save a lot of that effort. I suppose in theory the browser could optimize this as well but in practice it seems…

Yes but WHY don't the browser makers optimize for what seems to be this very common use case? Why does a third party library outperform them?

Re: Netflix Likes React

#42

Post by mynegation »

EGreg wrote: post #41
svachalek wrote: post #39

Earlier quoted context omitted.

Actually changing the DOM has a lot of implications. Recalculating CSS, layout, possible side effects that generate events, repainting, etc, etc. It's a lot of work to go through for an intermediate state that may not even last long enough to be visible to the user. Buffering and batching those changes can save a lot of that effort. I suppose in theory the browser could optimize this as well but in practice it seems…

Yes but WHY don't the browser makers optimize for what seems to be this very common use case? Why does a third party library outperform them?

Because when your code changes DOM, browser does not know whether you are going to stop at it for now, or do something else, so it has to re-render. In React you explicitly request application of virtual DOM changes to real DOM once you are done.

Re: Netflix Likes React

#43

Post by serve_yay »

cnp wrote: post #36
serve_yay wrote: post #27

Earlier quoted context omitted.

Boy, people never want to accept this. On my team, designers write the HTML. They own markup & styling. Designers don't want to dig through JS files to change markup, but an even bigger problem is that it's only kinda-sorta markup. For example, if you want to set a class on an element in JSX, it's not class="", it's className="". Because class is a reserved word in JS. How many other little warts like that are there,…

"How are they supposed to remember stuff like that?" Designers are never given enough credit. If they can handle all of the insanities of CSS (and various preprocessors), this will seem like cake. Its just a single `render` method, generally living at the top or the bottom of a file; nothing complex. Additionally, you stub out your static html markup first -- just like in a template -- and then you add interactivity.…

No, I explicitly told them about this and they said it sounded like a nightmare. I have gotten responses like yours - that basically I don't think highly enough of designers. On the contrary, I don't think they should have to waste their time with such things just because the JSers want to do things a certain way.

A wrinkle I did not mention is that we are in the process of transitioning how we do views. The new stuff is Ractive, but the old stuff is another library whose templates are also straight HTML. So using JSX would not only incur the aforementioned problems but also "wait, this is JSX so I should use this attribute name, and this is HTML so I should use this one." It just sounds shitty to me. And to them.

The situation is not designers can't handle it, the situation is they shouldn't have to deal with that kind of crap.

Re: Netflix Likes React

#45

Post by jonathancreamer »

mynegation wrote: post #42
EGreg wrote: post #41

Earlier quoted context omitted.

Yes but WHY don't the browser makers optimize for what seems to be this very common use case? Why does a third party library outperform them?

Because when your code changes DOM, browser does not know whether you are going to stop at it for now, or do something else, so it has to re-render. In React you explicitly request application of virtual DOM changes to real DOM once you are done.

Great explanation.

Re: Netflix Likes React

#46

Post by grrowl »

EGreg wrote: post #31

Can someone explain to me why virtual DOM is faster than DOM implementations of browsers?

React simply stores a /representation/ of what the DOM looks like (just the tree of nodes). When actually hitting the DOM, the browser recalculates styles, layout, and may preemptively calculate other things for speedier rendering. Additionally, it's a lot "heavier" so jumping through a node's children, children's children, etc. is much more expensive than plain nested objects. Therefore, it's most efficient to wait until the browser is actually about to render (requestAnimationFrame) and update only what is different in one go.

More specific details here: http://facebook.github.io/react/docs/reconciliation.html

Re: Netflix Likes React

#47

Post by robertfw »

ufo wrote: post #32
drawkbox wrote: post #20

Earlier quoted context omitted.

React has a better chance because it is a micro framework or component or just the V like you mentioned. Typical evolution of new tech is monolithic to micro, frameworks to components/modules/libraries. In the end micro frameworks or libraries allow more flexibility to change over time. Always bet on the micro frameworks and libraries, they can be swapped more easily and typically don't create blocks in overall archi…

React is quite large in terms of lines-of-code. I would refer to it as a mili-framework instead of a micro one :)

I would say that lines of code is not a useful metric. From a developer standpoint, what I care about is how much "surface" a library adds, and in how many places. The React API is relatively small, easy to understand, and confined to a single place - rendering my views.

Re: Netflix Likes React

#49

Post by serve_yay »

untog wrote: post #38
codexon wrote: post #35

Earlier quoted context omitted.

I am fairly certain that Ractive templates are similar to JSX in terms of overhead. If you don't like compiling JSX you can run it with the JSX client compiler at the cost of compiling it on every client. Ractive templates are parsed in JS just like JSX, which is why you have ractive compilers like this https://github.com/ractivejs/rv

I think the difference the OP mentioned is that Ractive templates are mustache-formatted strings, and can be stored in external files. So you have a JS file and a template file, not the combination of both you find in React.

Yes, indeed. I actually tried for a bit to get React templates in their own files separate from the JS, and I just couldn't do it. I know the React team's reasoning for why it's this way, but I still think it should be something devs can do if they want.

Re: Netflix Likes React

#50

Post by blktiger »

mynegation wrote: post #42
EGreg wrote: post #41

Earlier quoted context omitted.

Yes but WHY don't the browser makers optimize for what seems to be this very common use case? Why does a third party library outperform them?

Because when your code changes DOM, browser does not know whether you are going to stop at it for now, or do something else, so it has to re-render. In React you explicitly request application of virtual DOM changes to real DOM once you are done.

In theory they could add some new methods to the DOM api to allow for this, but it would be non-standard and currently none of the browsers have it.

Something like this maybe?

batchDomChanges(); ... dom changes here ... flushDomChanges();

Post reply on HN