Reactive MVC and the Virtual DOM • Hacker News Board

Re: Reactive MVC and the Virtual DOM

#21

Post by [deleted] » Mon, Jun 08, 2015, 8:22 AM UTC

thedz wrote: post #10

avodonosov wrote: post #8

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

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.

[deleted]

Re: Reactive MVC and the Virtual DOM

#22

Post by WalterGR » Mon, Jun 08, 2015, 8:23 AM UTC

malkia wrote: post #19

thedz wrote: post #10

Earlier quoted context omitted.

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.

The missing part in the DOM is: freeze() doLotsOfUpdates() thaw() 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()).

Is there any ongoing effort to add 'freeze' and 'thaw' to the standard? Or any browsers that have added them?

Re: Reactive MVC and the Virtual DOM

#23

Post by Yaggo » Mon, Jun 08, 2015, 9:59 AM UTC

malkia wrote: post #19

thedz wrote: post #10

Earlier quoted context omitted.

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.

The missing part in the DOM is: freeze() doLotsOfUpdates() thaw() 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()).

Isn't requestAnimationFrame basically that?

Re: Reactive MVC and the Virtual DOM

#24

Post by vcarl » Mon, Jun 08, 2015, 2:52 PM UTC

masklinn wrote: post #17

vcarl wrote: post #15

Earlier quoted context omitted.

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.

Re: Reactive MVC and the Virtual DOM

#25

Post by avodonosov » Mon, Jun 08, 2015, 2:58 PM UTC

malkia wrote: post #19

thedz wrote: post #10

Earlier quoted context omitted.

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.

The missing part in the DOM is: freeze() doLotsOfUpdates() thaw() 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()).

Our scripts are executed in a freeze mode.

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.

Google about "DOM reflow"