
React: What WPF Should Have Been - yinso
https://wizardsofsmart.wordpress.com/2016/03/04/react-what-wpf-should-have-been/
======
maxsilver
I don't understand why the author wanted Microsoft to use HTML / CSS / SVG. If
Microsoft had actually done that, and wanted or needed anything custom or
unique, they would just be accused of "embracing and extending" the
technology, as they had been previously.

It's seems like the XAML they went with is actually the better option -- it's
close enough to other markup languages that any developer can pick it up with
minimal effort, but not exactly the same so they can make any changes they
want without hurting anyone else's compatibility or the larger ecosystem.

And (totally subjectively) XAML is actually _nicer_ for developers and users
than HTML+CSS+JS in some areas, if your willing to invest just a tiny amount
of time to learn it.

\--

Plus, Microsoft's UWP also lets you use a web browser too, if you prefer. If
you feel your markup is better in HTML+CSS+SVG, Microsoft already supports
that as well - [https://docs.microsoft.com/en-us/windows/uwp/get-
started/cre...](https://docs.microsoft.com/en-us/windows/uwp/get-
started/create-a-hello-world-app-js-uwp)

~~~
dev360
> they would just be accused of "embracing and extending" the technology

Well, that didn't happen with TypeScript. I think the perception of Microsoft
has changed a lot since Nadella took over because they have really worked
really hard to avoid the IBM trap.

~~~
sotojuan
Yes now they're known for monitoring your computer usage and updating it while
you're not looking.

~~~
lucideer
By a certain subset of people. I think the perception of Microsoft in the tech
community has become oddly polarised.

On one hand you have developers and power-users who use Windows and care about
privacy. And a probably much tinier number who don't use Windows but care
enough about other people's privacy.

On the other hand you have all the web/JS/FOSS tech folk on Linux and macOS -
these OSes have pretty tiny usage stats over all but I'd guess relatively high
within that community - who don't care so much about Windows and as such just
see the positive results of their FOSS efforts.

I wonder who's winning...

------
recursive
I think Windows wanted to use a UI language that had a solution to vertically
centering an element, and other kinds of more advanced constraint-base
layouts.

I know flexbox and stuff exist _now_ , but I think it would have been a
mistake to adopt HTML with its document-centric model to represent Windows
applications.

~~~
c-smile
That's true. Desktop UI has a set of requirements that is still not achievable
in modern browsers (and inherently in Electron).

Conceptually there are still no ways at the moment to reproduce full set of
canonic layout managers from AWT:
[https://docs.oracle.com/javase/tutorial/uiswing/layout/visua...](https://docs.oracle.com/javase/tutorial/uiswing/layout/visual.html)

Partial attempts to introduce flexibility in CSS were made only recently -
flexbox and grid specifications.

But even those attempts look quite random and far from being well thought. For
example concept of flex (portion of free space) in flexbox is defined by
_property_ flex, but in CSS Grid module the same concept is defined by 'fr'
free space _units_. Yet the same entity in HTML was initially known as *
(asterisk) units (<frame> and <table> metrics). (All these are expressed by *
units in Sciter in their initial meaning).

I suspect that such no-one-is-responsible-for-overall-architecture in CSS was
one of major motivations in XAML/WPF appearance.

------
ComputerGuru
I think this is an article written by someone that does not have an
appreciation for static typing, ahead of time compilation, and the compiler
benefits thereof. Also, it seems that a deeper study of WPF is warranted since
some things it is claimed WPF cannot do are, in fact, quite possible.

~~~
polskibus
You can use Typescript with React (TSX instead of JSX) and benefit from static
typing.

------
m0ther
In WPF you can completely sidestep XAML and get direct access to the rendering
engine to run your own measure, arrange, and drawing code. Can you do that in
React? If not, WPF is what WPF should have been.

XAML is WPF in easy mode.

~~~
kitsunesoba
How flexible is this "sidestepping"? Could one build an implementation of
another UI toolkit (like Cocoa) on top of it?

~~~
douche
You can park a DirectX context in a WPF window or control. From there it is
off to the races, implementing anything you can imagine from scratch.

~~~
m0ther
I don't understand why Microsoft has been keeping this a secret for so long.
If you want a taste of what can be done in WPF when you take the training
wheels off; find yourself a copy of the now discontinued Windows Media Center.
It's UI is built on WPF.

It's such a shame WPF is in maintenance mode instead of active development.
I'd imagine a big reason for that is that it didn't gain the level of
popularity Microsoft hoped it would. I don't think they did a good job of
explaining and evangelizing it since release. UWP/Win2d seems to be what was
meant to replace it, but it doesn't offer the same level of control and
compatibility at all. I'm sure there's some grand long term plan I'm not privy
to, but I'd be much happier in the short term if we could stop pushing windows
store apps and get back to building frameworks for the hardcore.

Did you know there was a managed version of DirectX 9? Have you looked into
C++/CLI? I'd love to understand the story of why the .net initiative changed
direction in the last decade. I'd love to hear the master plan.

~~~
pjmlp
The master plan is very easy to explain by any long time Windows developer
(back to 3.x days).

The political wars between WinDev (Windows and C/C++) and DevTools (Visual
Studio and .NET) divisions.

With the mismanagemnt that happened with Longhorn, the WinDev gained in
strenght Vista and Windows 7 happened, pushing aside all .NET related plans
into DevTools alone.

Then with the failure of the initial store model, the DevTools kind of won in
strenght got some of the ex-Midori devs, MDIL compiler became .NET Native and
at the last couple of BUILDs you very barely see any talk about using C++ for
UWP, rather portability across Linux/mobile OSes and ANSI C++ compatibility,
everything else is shown in C#.

------
whowouldathunk
UWP XAML supports typed binding expressions, so you get compile-time breaks if
refactoring doesn't catch it.

And what's the difference between this and "unidirectional data flow"?

    
    
        <TextBlock Text="{x:Bind PageTitle, Mode=OneWay}"/>

~~~
LeoNatan25
It's not a "cool" JS "dev" nonsense name? What's the difference between flux
and observer pattern?

------
jarjoura
The #1 reason React works for me is that the UI and code are in the same file.
It's so easy to go back and refactor changes when everything is right there.
The natural composability you get from that over time is such a huge win in
productivity and major wins for team scalability. The one-way data flow is
honestly just a natural outgrowth of that architecture.

WPF and its sister frameworks, Silverlight and UWP all promote this
disconnected way to develop the UI. Create a XAML file that then needs to be
carefully crafted in a way that hooks up to the code class files. It was
initially sold as an idea that designers would build the XAML and the
engineers would work on the code. They even released a mini-adobe lite suite
marketed to designers.

UWP in its latest iteration seems to acknowledge XAML's shortcomings. They
introduced a new new UI foundational framework call the VisualLayer (aka
DirectComposition). It reminds me a lot of iOS's CoreAnimation framework.

~~~
insulanian
> The #1 reason React works for me is that the UI and code are in the same
> file. It's so easy to go back and refactor changes when everything is right
> there.

We're bashing VB6 for this exact reason, and now this is cool again?

~~~
yazaddaruvala
I think its cuz the whole package just works.

Just inlining views into JS wouldn't have been good. But when you add
unidirectional data flow, composable components and lots of best practice
docs, then you have a system that works really well.

~~~
douche
VB6 just worked, too. In many ways, it worked better than the current
conglomeration of web-dev technologies that replaced it.

~~~
tonyedgecombe
The language was a bit iffy but boy was it productive, we seem to have gone
backwards in so many ways.

~~~
pjmlp
Which is why as full stack developer across native and web stacks, I try to
avoid web projects as much as possible.

------
revelation
This is crazy talk. Yes Microsoft momentarily offered a browser plugin called
Silverlight and it happened to use some WPF stuff but don't believe for a
moment that this somehow means they wanted to make XAML the better HTML or
have any sort of adoption beyond the Windows ecosystem. It was pretty much
just a somewhat enhanced language for describing a scene graph because nobody
wanted the code generation of the Forms days.

They strictly kept any sort of code or logic out of XAML, annoyingly so to the
point where you are writing converter classes to negate an expression. Compare
that with the mishmash that is React.

~~~
int_19h
> They strictly kept any sort of code or logic out of XAML, annoyingly so to
> the point where you are writing converter classes to negate an expression

For what it's worth, WPF does provide sufficient flexibility that it's
possible to add support for expression-driven converters using markup
extensions and an MSBuild task for compile-time codegen. Have a look at this:

[https://github.com/Microsoft/PTVS/blob/ebfc4ca8bab234d453f15...](https://github.com/Microsoft/PTVS/blob/ebfc4ca8bab234d453f15ee426af3b208f3c143c/Python/Product/Cookiecutter/View/CookiecutterSearchPage.xaml#L54)

It can also be used completely inline, i.e.:

    
    
        <TextBlock Text="{Binding Name, Converter={ext:Lambda 'x => x.ToUpper()'}"/>
    

This is the codegen step that extracts those lambdas from XAML and processes
them:

[https://github.com/Microsoft/PTVS/blob/6bf34d3611d34e94eddb6...](https://github.com/Microsoft/PTVS/blob/6bf34d3611d34e94eddb6388cfc5d100be70097e/Common/Tools/BuildTasks/ExtractLambdasFromXaml.cs)

and this is the helper classes that are used in its output:

[https://github.com/Microsoft/PTVS/tree/6bf34d3611d34e94eddb6...](https://github.com/Microsoft/PTVS/tree/6bf34d3611d34e94eddb6388cfc5d100be70097e/Common/Product/SharedProject/Wpf/LambdaConverter)

Note that it's language-agnostic; or rather, it uses the same language for
expressions that the project itself does (so long as that language has a
CodeDOM provider).

~~~
m_fayer
This is brilliant and needs to be extracted into a library of its own. Thanks
for surfacing this!

~~~
int_19h
I originally wrote this code back in 2011 with the intent to do just that
(after some production use to prove the concept - which did happen; we've been
shipping products that use this code since 2013)... but never found enough
interest to actually motivate me to go and make it happen. Looking at the
upvotes on this comment, I might reconsider :)

Of course, if anyone wants to take this code and go for it, you're quite
welcome. Note that it has been also licensed more permissively under MIT as
part of RTVS - probably a better starting point for that:

[https://github.com/Microsoft/RTVS/tree/master/src/Common/Wpf...](https://github.com/Microsoft/RTVS/tree/master/src/Common/Wpf/Impl/LambdaConverter)

[https://github.com/Microsoft/RTVS/blob/master/src/Common/Bui...](https://github.com/Microsoft/RTVS/blob/master/src/Common/BuildTasks/ExtractLambdasFromXaml.cs)

------
nightski
The funny thing is that he's primarily after unidirectional data flow and
anti-data binding. I can actually get behind that. I worked on several large
WPF projects many years ago and TBH I don't think it would be impossible to
implement a uni-directional/redux style system within WPF. Would be an
interesting project.

IF WPF was still the primary UI tech on Windows I probably could get behind
implementing such a library.

~~~
dman
What is the primary UI tech on Windows now?

~~~
pjmlp
XAML, which is the same XML description language as WPF uses, plus the backing
UWP controls, which are also quite similar to the WPF API.

Main differences is that XAML processing is implemented in C# in .NET, and in
C++/CX on UWP.

XAML on UWP supports static binding at compile time, and on WPF it is only
dynamic (x:Bind vs Binding).

Finally the actual classes backing the UI components aren't 100% compatible,
but do have most of the same methods and properties.

Anyone that knows WPF, shouldn't have any issue with XAML/UWP.

~~~
int_19h
> Main differences is that XAML processing is implemented in C# in .NET, and
> in C++/CX on UWP.

Most stock UWP components (the ones that come with the OS) are implemented in
pure C++ using WRL ([https://docs.microsoft.com/en-us/cpp/windows/windows-
runtime...](https://docs.microsoft.com/en-us/cpp/windows/windows-runtime-cpp-
template-library-wrl)). This is mainly because they were already being
actively implemented long before C++/CX became usable.

~~~
pjmlp
Thanks for the clarification.

------
c-smile
> 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?

Why to imagine? Sciter ( [https://sciter.com](https://sciter.com) ) is exactly
that - embeddable HTML/CSS engine for UI of desktop applications. And it was
built at the same time: [https://sciter.com/sciter/sciter-vs-
wpf/](https://sciter.com/sciter/sciter-vs-wpf/)

Its code already works on around 320 mln PCs and Macs "under the hood" so
far... Quite comparable with spread of WPF applications, no?

~~~
styfle
So this is Electron before Electron existed? Does it have File IO APIs?

~~~
c-smile
Primary goal of Sciter is to be an embeddable _UI engine_. You can embed it
into C/C++, .NET, Java, Go, Rust, Python etc. applications. Each of them have
mature File I/O primitives.

As of Sciter itself ... It does have file I/O to load/read resources and data
persistence from script but these are just auxiliary components to its main
function (UI).

------
jinushaun
I've developed in WPF/XAML and React extensively and couldn't agree more. The
fundamental problem with XAML, IMHO, was that it was a plain text file format
masquerading as source code. The experience of writing XAML broke down very
quickly the moment you try to do anything beyond hello world. You must use an
IDE. As a result, WPF/XAML always felt heavy, hard to use and over engineered.
WPF, XAML and Blend always felt like it was a tool built by people who did not
use it themselves.

React, in the other hand, is dead simple and lightweight.

------
dev360
I can see why the author is drawing this conclusion...

I wrote ASP.NET controls for a long time, and I see a lot of similarities in
how I structure react components and how I would have written WebControls in
ASP.NET.

I think in hindsight, my conclusion/realization from reading this article is
that the lost opportunity for Microsoft was to re-invent the whole
presentation layer with things like WPF and Silverlight, instead of trying to
make it actually fit within the technology stack that people had settled on
(HTML/CSS/JS).

~~~
styfle
This was actually how I pitched it to my ASP.NET dev team: "React Components
are WebControls for the front-end"

------
vorotato
It really makes me sad that the author talks about F#, but doesn't mention the
awesomeness that is F# -> JS babel that exists called Fable, which allows you
to write F# with React.

[http://fable.io/](http://fable.io/)

