Wednesday, May 14, 2014

Dangers of react and VirtualDom

This is a brain dump from a Twitter/IRC discussion with @panesofglass and @bryanedds.

So there is this brand-new thing called Facebook React and hype wave about Virtual DOM. I only skimmed this library, but here are some reasons why I remain sceptical:

  • Identity! Typical DOM trees are a lot more than the markup. They are full of pieces of state that are *opaque* - abstract types, and *mutable*. This is especially true if you use 3rd-party libraries, but even with vanilla DOM, input tag, once rendered, interacts with the user and updates its focus state, the position of the cursor, and so on. Can all of it be captured in a snapshot as a pure value? Does React do this? I will be interested to find out.
  • If the answer is yes, I would be interested in playing more with VDom. Taking this as a foundation for design, means you throw out all other UI libraries (Ext JS, Kendo, etc). It is like a campaign to rewrite the Internet, without mutable state. But who cares - still might be interesting.
  • WebSharper Formlets library we designed with Joel Bjornson a while back assumes the answer is NO, so it does work with third-party libraries. The cost is some care is taken to manage identity of things. As far as change propagation through a tree on *pure* values, hey, we have done that in Formlets too, there is nothing too magical there. There are some nasty things when you do higher-order combinators, such as "Formlet.Many", and we try to do a sensible thing but I am not entirely confident in the theory. Loic Denuziere can comment on Piglets better than I can, but I think is quite similar as far as VDom aspect is concerned.
  • Formlets do not have or need a Diff function. You only need a Diff function if you describe transformations from a Model type to your UI type (VDom or what have you) as functions. If you have combinators with more structure, this can be done implicitly. Check the source.
  • Before, managing identity made me feel really bad. Am I a functional programming or what? These days, I am slowly accepting the concurrent paradigm. This is a different worldview, where process calculi (Pi, CSP) play a foundation similar to lambda calculus in FP. The paradigm makes working with identity essential, natural, and effective. Excellent fit for the world of UI!
  • There is also the Dataflow/FRP paradigm. I tried a few times, but my brain is still to small to digest it. Things get quite crazy when you allow dynamic switching combinators Signal (Signal t) -> Signal t. So, in this space I most sympathize with the Elm language which, from my limited understanding, seems to take a stand and prohibit such combinators, or in fact even possibility of constructing a type Signal (Signal t) in its type system. Looks like a great design, cleaner implementation and many useful things you can build. Some Haskellers though claim that the more general design is a "solved problem". Perhaps.
  • Self-Adjusting Computation was recently pointed out to me. I am still working through the paper. Looks highly relevant.
  • What would I like for Formlets/Piglets vNext, given time? Mostly, I would like a solid *model*, one that even I can understand and explain, that gives a meaning to what is going on, and is reasonably cleanly mapped to the implementation. For that, looks like I still need to catch up on some studying.

Chat logs:

#websharper on Freenode