4 ms·
Having worked on production software with both WPF and React, I can tell you why React's "data binding" approach is categorically different (better, in my opini
by brandonbloom 12y ago
Having worked on production software with both WPF and React, I can tell you why React's "data binding" approach is categorically different (better, in my opinion) than WPF's.
Like many abstractions in WPF, bindings have a "shadow world" feeling, where they are their own little isolated DSL. With the React model, "bindings" are just JavaScript expressions. Sure, with WPF you can overload operators and create "ExpressionBinding" converters and play other tricks, but you can feel the seams between the subsystems.
On the topic of the scene graph: React's scene graph is an abstract service that you can only interact with in limited ways. WPF's scene graph is a big mutable machine with most of its moving bits exposed. To a first approximation, React's rendering strategy is laziness and WPF's rendering strategy is fixed point iteration. The former is much more likely to produce easy to understand and high performing UIs, even if it comes at the cost of making a few special use cases harder. In such cases, you can bypass the abstraction and muck with the platform guts, which seems to be the default choices in the dependency properties context.
- seanmcdirmid 12y agoRight, WPF's declarative databinding support is separated from imperative semantics, even if they can interact a bit (a databinding relationship can be formed and destroyed imperatively). But I've moved away from WPF to Glitch, which doesn't have that problem: all code runs in the same world, with dependency tracing, re-evaluation on dependency change, and logging to support rollback as needed. In that case, now I'm curious how React compares to what I'm working on right now. I've never heard anyone claim that laziness leads to more performant UIs. It has always been the opposite in my experience: by loosening up evaluation orders and allowing for glitching, you reduce the amount of book keeping needed to come up with optimal DAG-style re-computation orders. For example, consider a double-indirect (flat-map-style) dependency: countLabel.Content = folderView.Selected.Count; If count changes, you update the label. But if selected changes, you have to stop observing the previous selected folder's count property and start observing a new selected folder's count property. Carefully tearing down and building back dependency chains is tough, but if you just play lose with the dependencies, it is actually quite easy to handle (you might get some spurious re-evaluations). Note that WPF can't handle this without lots of hackery, which is one reason I moved all my UI work to Glitch (the other is that WPF is totally inappropriate performance wise for writing compilers and language-aware editors). I'm curious how React handles indirect state? Or does it need to do dependency tracing at all (it wouldn't if its not incremental; I can't tell by looking at the website)?
- brandonbloom 12y agoIt doesn't have to track dependencies at all, but it is certainly still incremental. Maybe you should study it before judging it.
- seanmcdirmid 12y agoI've looked at the examples; I guess we just have different definitions in what incremental means.