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.
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.
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
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-...