

Reactive MVC and the Virtual DOM - jacobr
http://futurice.com/blog/reactive-mvc-and-the-virtual-dom/

======
cageface
The pace of innovation in JS is inspiring. But as someone trying to get back
into front-end development after years of doing native apps it's also a little
bit discouraging that there's so little consensus on how web apps should be
built. It seems like today's hot new technique is tomorrow's discarded
anachronism. How do people actually get anything done when it's so hard to
build a stable foundation for anything?

~~~
Offler
Things are improving rapidly, depending on the scale you intend to build to
mature solutions are available for you.

As it stands I don't see a better view layer solution then React, but I think
you'd be best served learning it without using JSX so you can see exactly what
it does. JSX tricks some people into thinking React is some sort of markup
processor.

The older generation view solutions are usually string based templates with
embedded DSLs to manipulate the resulting DOM. React divorces itself from the
DOM totally and allows you to programatically generate and _compose_ the view.
Components and the separation from the DOM are React's great features.

Both Ember and Angular are trying to figure out how to integrate the React
functional feel into their new versions and are taking notes. I just don't see
them improving on React though at best they will copy.

~~~
cageface
I'm using React on a toy project and I'm pretty impressed with it so far. Once
I got a reasonable environment for editing and processing JSX things have
progressed pretty smoothly. Until web components hit this seems like the best
option. The library mentioned in the OP seems interesting but I think I'd
prefer to stick with React even if only for the much more established
community. In the long run I think consensus counts for a lot because most
things can be fixed if enough people are willing to chip in to fix them.

------
stevebmark
[https://github.com/staltz/mvi-
example/blob/master/src/views/...](https://github.com/staltz/mvi-
example/blob/master/src/views/items.js)

var modelItems$ = new Rx.BehaviorSubject(null); var itemWidthChanged$ = new
Rx.Subject(); var itemColorChanged$ = new Rx.Subject(); var removeClicks$ =
new Rx.Subject(); var addOneClicks$ = new Rx.Subject(); var addManyClicks$ =
new Rx.Subject();

As someone unexperienced with the Rx library, this is completely unreadable.

~~~
glibgil
It's assigning the result of a constructor to a variable. It's JavaScript. So
this isn't your thing I guess.

~~~
stevebmark
As someone actively trying to damage his (how did I guess you were a guy?!)
community with dismissive, condescending and anti-inclusive hatred, in a
community already battling against these problems, I hope you consider making
programming _not_ your thing.

------
glifchits
virtual-dom may be faster than React.js in benchmarks. However the React
example [1] that the author rebuilt with MVI [2] is much slower with many
elements. What's the deal here?

[1] [http://binarymuse.github.io/react-
primer/build/index.html?6](http://binarymuse.github.io/react-
primer/build/index.html?6) [2] [http://staltz.com/mvi-
example/](http://staltz.com/mvi-example/)

~~~
nthtran
The author didn't include an optimisation that the React example has.

In React you can use the PureRenderMixin [0] to avoid re-rendering subtrees if
the arguments passed in are the same. In virtual-dom there's something similar
called Thunk [1].

I did a partial implementation of the demo here [2] using Thunk. You can see
that it performs much better than React for many thousand items. Adding items
is also faster using virtual-dom.

[0] [http://facebook.github.io/react/docs/pure-render-
mixin.html](http://facebook.github.io/react/docs/pure-render-mixin.html)

[1] [https://github.com/Raynos/vdom-thunk](https://github.com/Raynos/vdom-
thunk)

[2] [http://nthtran.github.io/mercury-
demo6-v2/](http://nthtran.github.io/mercury-demo6-v2/)

~~~
glenjamin
From a quick look at the demo, the React version also doesn't use
PureRenderMixin.

The optimisation that the React version has that is not applied in the
virtual-dom version is list keys.
[http://facebook.github.io/react/docs/reconciliation.html#key...](http://facebook.github.io/react/docs/reconciliation.html#keys)

I don't know if virtual-dom provides an equivalent feature, but I imagine it
would be straightforward to add if not.

~~~
nthtran
The React demo does use PureRenderMixin [0].

And virtual-dom also supports keys.

[0] [https://github.com/BinaryMuse/react-primer/blob/gh-
pages/dem...](https://github.com/BinaryMuse/react-primer/blob/gh-
pages/demo6/item.jsx#L44)

~~~
glenjamin
Ah yes, I only read the top file, didn't realise the demo was split into
multiple components.

Do you have a link to the source for the virtual-dom version?

------
plaguuuuuu
This is reaaaally cool. It's pretty much _exactly_ what I've been looking for
in a JS framework.

The cool thing is that rendering is totally separate. Virtual dom? If that
floats your boat, cool. You can just as easily bake Knockout into the mix and
you'd be flying through implementation. It'd be both easy and flexible. Could
probably componentise the UI very easily too. I dig it.

~~~
bsimpson
The whole "single concern" analogy fell apart there. "View output: a Virtual
DOM rendering of the model, and raw user input events" \- it's the only
component that does two things. Moreover, if this is just the virtual,
unrendered DOM, where do the events come from?

~~~
staltz
DOM events are being delegated to Virtual DOM event handlers. This is what
'dom-delegator' does, it comes from mercury:
[https://github.com/Raynos/mercury/blob/master/docs/dom-
deleg...](https://github.com/Raynos/mercury/blob/master/docs/dom-delegator.md)
Still, the View doesn't "do" two things. It does just one: renders virtual
elements. The virtual element output just happens to consist of two things:
the element, and events coming from that element.

In tests where the View is isolated from the browser and from the Model-View-
Intent cycle, virtual DOM events will actually not exist at all, because there
is no user interacting with the view. Virtual DOM events only happen, and only
make sense, when everything is plugged in and executing in the browser with
user interaction.

------
paublyrne
Not nearly enough programming articles use Zelda games as analogies for the
concepts they discuss.

This one does.

~~~
tosh
Loved the analogy. These things really help in conveying new concepts if they
are well picked.

