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

Reactive MVC and the Virtual DOM

futurice.com

Post reply on HN
Print view View original

11–20 of 25 posts

Re: Reactive MVC and the Virtual DOM

#11

Post by avodonosov »

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.

Yes, yes! I also think about this.

Re: Reactive MVC and the Virtual DOM

#12

Post by mrcwinn »

rattray wrote: post #9

I like the idea of moving that arrow the way he does. Everything else was just less convincing. The real power of React is composable components that are easy to think about. I don't think the author really "got" this; if he was building "complex state machines ... and [mixing] multiple concerns in one component", he was just doing it wrong. I also don't love the idea of stores depending on each other. In my experien…

Completely agree. Looking at his eventual realization of these ideas, Cycle.js, it's just a complete mess in terms of declarative, easy to understand components. The beauty of React, beyond its simple lifecycle API and virtual DOM, is that you can glance at a component and very quickly reason what it does and how it works. I can't say the same for anything that came out of this article.

There's a tendency in JavaScript development especially to overthink, over-engineer, and over-abstract. We're still in the middle of the woods with JavaScript application development. I hope we get out soon!

Re: Reactive MVC and the Virtual DOM

#13

Post by untog »

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…

To be fair, the DOM is that abstraction layer already. It just performs horribly.

Re: Reactive MVC and the Virtual DOM

#14

Post by BinaryIdiot »

Good write-up and similar to some of my findings. In fact I like the event emitting / messaging pattern so much I wrote a little library called msngr.js (https://github.com/KrisSiegel/msngr.js) to do the same type of thing.

I'm not entirely convinced of the separate "renderer" or really the act of updating a virtual dom but I do like the model-view-intent. What I've done is something pretty similar though typically I combine the model and the view in all cases but the main application itself. Basically the breakdown is like this:

Application controller - initializes application components / authorization / anything necessary for startup

Web components - Either through webcomponents.org polyfills or polymer these are the individual components that make up the user interface of the web application. Each web component is entirely responsible for its interaction with the user. It subscribes to messages when it should take in updates and it emits the data the user inputs.

Application libraries - Handles the other end of messaging; has zero interaction with anything within the DOM. Subscribes to data that gets emitted from the web components and emits data that the web components need to display to the user.

I try to keep things as basic as possible. I'm still experimenting and working on an example web application using msngr.js that I can actually release as open source but I am a fan of this type of pattern. The best part of this is I can do full unit testing on the application libraries with zero DOM and the web component side of things can be fully tested with mocked results.

Re: Reactive MVC and the Virtual DOM

#15

Post by vcarl »

untog wrote: post #13
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…

To be fair, the DOM is that abstraction layer already. It just performs horribly.

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.

Re: Reactive MVC and the Virtual DOM

#16

Post by baddox »

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.

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.

Re: Reactive MVC and the Virtual DOM

#17

Post by masklinn »

vcarl wrote: post #15
untog wrote: post #13

Earlier quoted context omitted.

To be fair, the DOM is that abstraction layer already. It just performs horribly.

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.

Re: Reactive MVC and the Virtual DOM

#18

Post by akvadrako »

baddox wrote: post #16
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.

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.

Re: Reactive MVC and the Virtual DOM

#19

Post by malkia »

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.

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

Re: Reactive MVC and the Virtual DOM

#20

Post by malkia »

untog wrote: post #13
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…

To be fair, the DOM is that abstraction layer already. It just performs horribly.

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?)

Post reply on HN