4 ms·

> React is a giant step towards functional programming. Windows is definitely nothing like that. Err, that's not entirely true for MVVM apps, where views are j

> React is a giant step towards functional programming. Windows is definitely nothing like that. Err, that's not entirely true for MVVM apps, where views are just declarative markup that are rendered (retained mode) based on logical state provided by data bindings. It's been like that ever since XAML was introduced in 2006.

dustingetz 11y ago
MVVM makes ubiquitous use of mutable state which means model change listeners, callbacks calling callbacks etc, FP/React is about using immutable state to dodge all these problems by design. http://www.dustingetz.com/2013/09/12/comparison-knockout-angular-react.html http://www.dustingetz.com/2013/09/12/comparison-knockout-ang...
- Aleman360 11y ago
  The point is that in both React and XAML apps, you (usually) don't write code to mutate the View. In your code, the View is just a declarative construct. There's nothing stopping you from making immutable ViewModels in MVVM, other than bad perf (which React would presumably also suffer from on larger apps).
  - xixixao 11y ago
    The point is React is not just View, each component is a view plus the part of the "controller"/"presenter" that would take care of populating the view. And the controller/presenter is where state is always encapsulated, which React gets (mostly) rid off.
  - tracker1 11y ago
    Facebook doesn't seem to perform so badly in terms of a larger app. More varied components on a page than most applications in general. Most of the quirkiness I see in FB tends to come from how they deal with eventual consistency with their backend in order to scale to millions of simultaneous users. Most applications don't have the latter problem.
    - Aleman360 11y ago
      I bet they do a lot of shouldComponentUpdate, which kills the functional purity. XAML control properties do the equivalent of shouldComponentUpdate by default. Same ideas, just doing diffs in different places.
      - dustingetz 11y ago
        > I bet they do a lot of shouldComponentUpdate, which kills the functional purity. functional purity enables shouldComponentUpdate
- shoover 11y ago
  Adding a late comment to appreciate the MVVM synopsis in your blog post. The pain of tracking lots of callbacks and cascading updates is a lot of what Pete Hunt was talking about in Be Predictable, Not Correct [0], but there's not a lot of discussion applying that analysis to MVVM as for other forms of MV*. I find it's a real concern in WPF apps with much of any complexity. [0] https://www.youtube.com/watch?v=h3KksH8gfcQ https://www.youtube.com/watch?v=h3KksH8gfcQ
deleted 11y ago
[deleted]

dustingetz 11y ago

MVVM makes ubiquitous use of mutable state which means model change listeners, callbacks calling callbacks etc, FP/React is about using immutable state to dodge all these problems by design. http://www.dustingetz.com/2013/09/12/comparison-knockout-angular-react.html http://www.dustingetz.com/2013/09/12/comparison-knockout-ang...

Aleman360 11y ago
The point is that in both React and XAML apps, you (usually) don't write code to mutate the View. In your code, the View is just a declarative construct. There's nothing stopping you from making immutable ViewModels in MVVM, other than bad perf (which React would presumably also suffer from on larger apps).
- xixixao 11y ago
  The point is React is not just View, each component is a view plus the part of the "controller"/"presenter" that would take care of populating the view. And the controller/presenter is where state is always encapsulated, which React gets (mostly) rid off.
- tracker1 11y ago
  Facebook doesn't seem to perform so badly in terms of a larger app. More varied components on a page than most applications in general. Most of the quirkiness I see in FB tends to come from how they deal with eventual consistency with their backend in order to scale to millions of simultaneous users. Most applications don't have the latter problem.
  - Aleman360 11y ago
    I bet they do a lot of shouldComponentUpdate, which kills the functional purity. XAML control properties do the equivalent of shouldComponentUpdate by default. Same ideas, just doing diffs in different places.
    - dustingetz 11y ago
      > I bet they do a lot of shouldComponentUpdate, which kills the functional purity. functional purity enables shouldComponentUpdate
shoover 11y ago
Adding a late comment to appreciate the MVVM synopsis in your blog post. The pain of tracking lots of callbacks and cascading updates is a lot of what Pete Hunt was talking about in Be Predictable, Not Correct [0], but there's not a lot of discussion applying that analysis to MVVM as for other forms of MV*. I find it's a real concern in WPF apps with much of any complexity. [0] https://www.youtube.com/watch?v=h3KksH8gfcQ https://www.youtube.com/watch?v=h3KksH8gfcQ

deleted 11y ago

[deleted]