> The gist is to frequently re-render a complete and lightweight representation of the DOM, then apply a difference filter to detect the minimum changes that need to be made to the DOM. A similar technique has existed in game development long before React: re-render the game screen in every game loop, but only update the minimum portion of the screen which changed compared to the previously rendered screen.
Practically every desktop UI works that way (Windows API, X Windows, Java UI libs). It's funny to see how web programming in 2015 slowly reinvents the wheels known since 1970s.
The browser that is rendering the DOM also, ultimately, works that way, with various portions of the browser screen redrawing while others remain static.
So it's kinda funny that the modern state of web dev is adding another layer of that same approach on top of layers of that approach.
So one would have to reinvent this. Kind of reminds of propeties in some languages, runtimes and their UI's:
someForm.setWidth(500); // And it's updated right away on the screen, instead of being deferred, or put in some freeze()/thaw() mode. (disableUpdates() / enabledUpdates()).
When we modify DOM it becomes "dirty", and after our script finishes, reflow/re-render happens. But also, if our script queries DOM properties, like elem.clientHeight, DOM may need to perform the calculations in order to return us correct values, reflecting all the recent property changes. For example, if we access element.clientHeight browser may need to calculate re-flow (I recently encountered very slow clientHeight calculation by FireFox).
So, if we only modify DOM properties, all the re-rendering is deferred till the end of script.
React's virtual DOM (and other virtual DOM implementations) aren't just "adding another layer of that same approach," because the browser's DOM doesn't give you any way of diffing against a previous DOM state then performing the minimal operations needed to realize the new state.
The point is that the browser internally maintains an analogue of the virtual DOM in React, and compares the diffs so only some parts of the screen must be updated.
I've been wondering about additional benefits to abstracting away the DOM, about how practical it would be to then have UIs constructed in different environments that runs off the same base logic.
I suppose that's the value proposition of React Native; write your javascript logic once and just rewrite the render function for Android, iOS, web, any any future target that implements the API.
The value proposition is declarative UI definition, vdom is how that proposition performs acceptably (or more than acceptably as it allows further optimisation due to pervasive use of pure functions) when layered on an imperative underlying structure.
Yeah I don't specifically mean the virtual DOM, I'm thinking more about the fact that your interactivity isn't coupled to the actual markup. If you avoid browser specific functionality, it would be super easy to port to another platform.
I don't think it performs poorly, it's simply missing functionality to stop update right away, but rather sit there wait for a bunch of commands to come in, and then update.
It's possibly missing this "mode" because of other factors (what if you never put it back in "updates enabled" mode?)
Practically every desktop UI works that way (Windows API, X Windows, Java UI libs). It's funny to see how web programming in 2015 slowly reinvents the wheels known since 1970s.