6 ms·

Reactive MVC and the Virtual DOM

70 points by jacobr 12y ago

paublyrne 12y ago
Not nearly enough programming articles use Zelda games as analogies for the concepts they discuss. This one does.
- tosh 12y ago
  Loved the analogy. These things really help in conveying new concepts if they are well picked.
- nickik 12y ago
  The best one is about continuations. Zelda N64 Timetravel.
glifchits 12y ago
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 12y ago
  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 12y ago
    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#keys http://facebook.github.io/react/docs/reconciliation.html#key... I don't know if virtual-dom provides an equivalent feature, but I imagine it would be straightforward to add if not.
    - nthtran 12y ago
      The React demo does use PureRenderMixin [0]. And virtual-dom also supports keys. [0] https://github.com/BinaryMuse/react-primer/blob/gh-pages/demo6/item.jsx#L44 https://github.com/BinaryMuse/react-primer/blob/gh-pages/dem...
      - glenjamin 12y ago
        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?
  - hackerboos 12y ago
    Thank you for commenting. Although I like the new pattern the author presented I almost dismissed it because the performance was significantly worse than the react example.
cageface 12y ago
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?
- ux-app 12y ago
  > How do people actually get anything done when it's so hard to build a stable foundation for anything? For me it's a matter of not chasing the latest hot tech, and instead using the right tool for the job and sticking with it. I also avoid using kitchen sink style frameworks. I'm much happier going vanilla JS and using small light weight libraries that do one thing well. The upshot to this is that you can often swap out a library with a newer one without a complete application rewrite (something that can't be said of frameworks).
  - cageface 12y ago
    In principle I like this approach but there are advantages with going with the larger frameworks too. For example, if I build something with Angular, I can take advantage of all the components, tutorials, SO posts etc that the community has generated. If I roll my own solution from a handpicked collection of third-party libraries I forfeit all that. I was until very recently leaning towards using Angular but now that they've announced that Angular 2.0 is practically a rewrite that also seems like a dead end. At the moment I'm rooting for Polymer/Web Components, even though I'm not sure I'm on board with all their design decisions, if only because it seems to be likely to generate enough consensus to be a stable platform to build on for the next several years. But even that isn't something I can actually use today to get work done.
- ebiester 12y ago
  We're having trouble getting it right still - that's what it says to me. The proliferation isn't going to stop anytime soon. If you're doing a simple system, it's really fine to stay with the old server-side rendered techniques. Otherwise, just pick one based on a few hours of research -- any of the front runners is going to be a good enough choice. (Angular, Ember, React)
plaguuuuuu 12y ago
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 12y ago
  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 12y ago
    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-delegator.md https://github.com/Raynos/mercury/blob/master/docs/dom-deleg... 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.
stevebmark 12y ago
https://github.com/staltz/mvi-example/blob/master/src/views/items.js https://github.com/staltz/mvi-example/blob/master/src/views/... 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 12y ago
  It's assigning the result of a constructor to a variable. It's JavaScript. So this isn't your thing I guess.
  - stevebmark 12y ago
    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.
- staltz 12y ago
  That's boilerplate. This example might look cleaner to you, where boilerplate is being removed in an MVI framework: https://github.com/staltz/cycle/blob/master/examples/hello/hello.js https://github.com/staltz/cycle/blob/master/examples/hello/h...

70 points by jacobr 12y ago

paublyrne 12y ago

Not nearly enough programming articles use Zelda games as analogies for the concepts they discuss. This one does.

tosh 12y ago
Loved the analogy. These things really help in conveying new concepts if they are well picked.
nickik 12y ago
The best one is about continuations. Zelda N64 Timetravel.

glifchits 12y ago

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 12y ago
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 12y ago
  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#keys http://facebook.github.io/react/docs/reconciliation.html#key... I don't know if virtual-dom provides an equivalent feature, but I imagine it would be straightforward to add if not.
  - nthtran 12y ago
    The React demo does use PureRenderMixin [0]. And virtual-dom also supports keys. [0] https://github.com/BinaryMuse/react-primer/blob/gh-pages/demo6/item.jsx#L44 https://github.com/BinaryMuse/react-primer/blob/gh-pages/dem...
    - glenjamin 12y ago
      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?
- hackerboos 12y ago
  Thank you for commenting. Although I like the new pattern the author presented I almost dismissed it because the performance was significantly worse than the react example.

cageface 12y ago

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?

ux-app 12y ago
> How do people actually get anything done when it's so hard to build a stable foundation for anything? For me it's a matter of not chasing the latest hot tech, and instead using the right tool for the job and sticking with it. I also avoid using kitchen sink style frameworks. I'm much happier going vanilla JS and using small light weight libraries that do one thing well. The upshot to this is that you can often swap out a library with a newer one without a complete application rewrite (something that can't be said of frameworks).
- cageface 12y ago
  In principle I like this approach but there are advantages with going with the larger frameworks too. For example, if I build something with Angular, I can take advantage of all the components, tutorials, SO posts etc that the community has generated. If I roll my own solution from a handpicked collection of third-party libraries I forfeit all that. I was until very recently leaning towards using Angular but now that they've announced that Angular 2.0 is practically a rewrite that also seems like a dead end. At the moment I'm rooting for Polymer/Web Components, even though I'm not sure I'm on board with all their design decisions, if only because it seems to be likely to generate enough consensus to be a stable platform to build on for the next several years. But even that isn't something I can actually use today to get work done.
ebiester 12y ago
We're having trouble getting it right still - that's what it says to me. The proliferation isn't going to stop anytime soon. If you're doing a simple system, it's really fine to stay with the old server-side rendered techniques. Otherwise, just pick one based on a few hours of research -- any of the front runners is going to be a good enough choice. (Angular, Ember, React)

plaguuuuuu 12y ago

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 12y ago
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 12y ago
  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-delegator.md https://github.com/Raynos/mercury/blob/master/docs/dom-deleg... 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.

stevebmark 12y ago

https://github.com/staltz/mvi-example/blob/master/src/views/items.js https://github.com/staltz/mvi-example/blob/master/src/views/... 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 12y ago
It's assigning the result of a constructor to a variable. It's JavaScript. So this isn't your thing I guess.
- stevebmark 12y ago
  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.
staltz 12y ago
That's boilerplate. This example might look cleaner to you, where boilerplate is being removed in an MVI framework: https://github.com/staltz/cycle/blob/master/examples/hello/hello.js https://github.com/staltz/cycle/blob/master/examples/hello/h...