HN Theater @HNTheaterMonth

Sorry, I don't remember the link. It may have been this talk from 2013, but I haven't rewatched it: https://www.youtube.com/watch?v=XxVg_s8xAms

However, if you check out the History section [0] on Wikipedia you will see this confirmed:

> React was created by Jordan Walke, a software engineer at Facebook, who released an early prototype of React called "FaxJS". He was influenced by XHP, an HTML component library for PHP.

[0]: https://en.wikipedia.org/wiki/React_(web_framework)#History

There are added benefits for an immutable / FRP style of building a UI, but I think you're more interested in the rest of my answer.

Nothing to be confused about, you have a valid hypothesis: "Rendering and Diffing in Javascript is slower than DOM manipulation". However, all hypothesis need to be experimented before having any real meaning.

It just happens that testing this hypothesis and finding it invalid was the foundation for React.

Watch this video[https://www.youtube.com/watch?v=XxVg_s8xAms] I think it does a good job discussing this hypothesis and why they chose not to worry about it.

⬐ amelius

So let's assume I have a listbox with N elements in it. I assume the render() method has to visit each of these elements every time an updates takes place, so it is O(N). Please correct me if I'm wrong here.

Now for a certain value of N, things will become slow, unresponsive. I'm guessing now that this value of N is above the value where the browser cannot handle this number of elements anyway. Is this correct?

PS: I understand that it is possible to completely optimize the listbox case. But that is not the scenario I'm interested in. I'm interested most and above all in the typical use-case. I'm just using a listbox as an example here. Just replace it by any other sufficiently complicated and customized UI component if desired.

⬐ WickyNilliams

A render in react doesn't return DOM elements. Render is a pure function which projects app state into a description of the view. Let's call this description A, so render(state) -> A. When state changes and render is called a second time we get a new description, render(newState) -> B. A diff is then applied to them diff(A, B). The diff can then be translated to an update strategy for the actual DOM (or in this case, native components). From this the smallest set of changes are applied to bring the DOM in line with the current state. It turns out it's far quicker to diff objects in memory than query the DOM. The DOM is treated as a stateless rendering engine, with progressive updates applied as app state changes.

Of course, in your example, there is a point where N gets so large that it poses problems. This is true whether you're using the raw DOM or an abstraction like React. The solution is the same in either case - cull non-visible elements from the render tree (again react makes this as efficient as possible).

EDIT: it's also worth noting you can skip updating entire subtrees in React with shouldComponentUpdate hooks. This avoids the case where you go through the render/diff cycle and it turns out there is no difference, and so nothing to update. Paired with immutable data structures this method can be a simple reference equality check (shallow equals) oldState !== newState, and therefore can really get the most efficient rendering possible

⬐ amelius

But how do I remove non-visible elements from the render-tree? Is this something I have to do explicitly like I would have to do without React? Or does React somehow take care of this for me?

⬐ WickyNilliams

Amelius, I cannot reply to you directly for some reason. Anyway...

So say you're rendering some long list of items. Because react is just plain JS (no templates!), you will map the array of items to components in your render. You give each item a key so that react can reconcile components across renders. If component with same key is returned from render next time then it's kept in the DOM (and any updates applied), if not then it's removed. So the involved part becomes determining what is visible or not, and then slicing your list of items to only map a subset. This is the more involved part. I haven't built anything like this myself, but I'm guessing it basically boils down to: listening to scroll events on container, determining y offset, get height of contaoner and height of elements, use that to determine which items in list should be mapped to components in render. That bit is the same whether react or not.

See James Longster's epic blog post "Reducing User Interface Complexity, Or Why React Is Awesome" [0]. Where he details this kind of approach with his for-demp-purposes-only react-like lib.

[0] http://jlongster.com/Removing-User-Interface-Complexity,-or-...

⬐ amelius

Thanks a lot for this detailed explanation.

If I get this clearly, then still:

render() -> returns N items every time it is invoked

And React will diff those N items against the DOM (using a key) every time an update is required.

So, to me it appears that still O(N) amount of work has to be done every time something small changes in the list.

This is not necessarily a bad thing. But here we assume that doing render() is faster than actually building the DOM from scratch, even though they have the same computational complexity, O(N).

Anyway, I'll have a look at that link. Very interesting, thanks again.

⬐ WickyNilliams

no, it doesn't compare to DOM, it compares to the last result of render - an important difference performance-wise. the DOM is many times slower to query than plain objects.

also remember big-O notation doesn't really capture the essence of the problem here. looping through and querying N DOM elements is probably orders of magnitude slower than doing the same with N objects in memory