I’ve been learning and using React, and I like it’s general approach to building UIs. I really like the unidirectional data flow, though I’m still on the fence about virtual DOM. I get the benefits and really like that it makes testing really easy. However, I am not sold on its being unquestionably better than directly manipulating the DOM or Google’s Incremental DOM. Nevertheless, React, Om, Elm, and others have proven it a viable and fast approach.
One of the best advantages of the aforementioned frameworks is they all allow you to compose custom, reusable elements or components building off of existing HTML elements. (I think WebComponents allows something similar, though I have not personally liked its direction.) Another advantage is that you can declare all these things within JavaScript or your transpiler of choice.
I liked many similar attributes of WPF and XAML when I worked on desktop software. At that time, I had just taken a job doing .NET consulting and was still learning .NET. I had mostly tinkered with VB6, PHP, Ruby, Python, SVG, and XForms to build desktop and web applications. I really enjoyed adding SVG and XForms into web apps to make them richer, though I never quite mastered either and, at the time, both required plugins that didn’t often play well together. XAML offered a chance to do something similar with desktop applications, and I enjoyed it a lot.
However, I worried that Microsoft had opted to build their own markup language when so many, similar languages already existed and offered a nice composition story. Also, I recall thinking that the previous strategy of walled gardens appeared ready to collapse. Fast forward a few years, and Web Standards were alive and well in the form of HTML5 (with SVG baked in) as Chrome and Firefox began picking up market share, and XAML was isolated to the Microsoft platform. A few other vendors had similar markup language efforts, all of which remained isolated to their own platforms.
Imagine, if you will, a different scenario. Had Microsoft been prescient enough to see the revival and adoption of HTML and SVG and built WPF on top of these, do you think things would have gone differently? XAML had features of XForms without the complexity. XForms didn’t survive, so it is possible that a XAML built on HTML and SVG with some of the XForms-like features could perhaps have been the baseline for HTML5. Microsoft developers would have a single UI platform to write web and desktop applications.
One can dream.
The one thing Microsoft didn’t solve was the unidirectional data flow. I’m not sure they would have solved that. Data binding was and still is a popular approach. I dislike it b/c I’ve so often been bitten by refactoring things and those refactorings not making it into the UI markup templates. However, XAML didn’t require the markup file; you could/can also create those elements in your programming language. I first encountered the unidirectional style in a sample F# WPF application. There is no JSX equivalent, but the unidirectional data flow, immutable values, and all the rest are certainly possible. Yet WPF is still primarily known more for its data-binding abilities and preferred MVVM than for its flexibility in allowing different styles of development.
I can imagine an alternative reality in which React was just a JavaScript implementation of something realized first by Microsoft in .NET. Unfortunately, that didn’t happen. Nevertheless, one could write a set of elements for WPF to mimic HTML and SVG and then layer on a version of React, were one of a mind to do so. Even if not, you may still find it useful to give F# a try in order to mimic the same unidirectional data flow you can find in React. You can see an example in the recent Community for F# recording with Phil Trelford on F# on the Desktop.
Wizards of Smart 