React: What WPF Should Have Been | Hacker News Reader

React: What WPF Should Have Been

wizardsofsmart.wordpress.com

55 pointsyinso64 comments

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...

> 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.

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

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...

Yes, but apparently they are the only bad ones, because people are perfectly fine when Apple or Google do it.

WPF was released in 2006 though. The Microsoft of 2006 definitely would've been pilloried for EEE if WPF had been built on web technologies. (Not that the Microsoft of 2006 ever would've done that)

In my experience XAML can be a massive footgun if you don't know what you're doing. Sure, world-class geniuses are using it to build (still) the best IDE on the planet, but on your everyday development team it can backfire. One of React's biggest selling points is that it has a sort of "pit of success" instead. Partly from the mandatory one-way binding, and partly because of the choice to allow integrating any kind of UI "thing" into the component model.

You can't learn WPF and XAML in a tiny amount of time, it is substantial.

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.

And they did fix that for the JS applications (WinJS and the like) by using and implementing their own idea, the "grid", which no one else supports to this day, but in a lot of ways is based on the ideas of UI design from XAML/WPF.

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...

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.

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.

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

Elm was among his examples, and the one he chose to demonstrate the vdom's viability when it comes to performance.

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.

Wouldn't that just be JavaScript?

No. Is the react rendering engine rendered by Html5 Canvas or WebGL? That would be the closest analogue.

In WPF you can get direct access to their retained mode graphics system, built on top of direct x, and ignore XAML completely.

Before making a claim like "React is what WPF should have been", the author should have done a lot more research into what WPF is and what could be done with it. The beauty of WPF isn't in XAML, it is in WPF's underlying framework and rendering engine. XAML is WPF's training wheels.

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

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.

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.

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#.

https://msdn.microsoft.com/en-us/library/system.windows.medi...

You can build whatever you want on top of the WPF foundation. That's how .net framework API's work.

WPF is a rendering engine, with a control management system build on top of it. XAML is an HTML like way of defining controls, but you don't have to use it. XAML is sugar, and I generally avoid it unless my application is super simple. You don't have to use their control management system either, you can go strait for the retained mode graphics system.

As much as Microsoft tries to make windows development look like web development through sugar on top (XAML is the most recent) to attract the new generation of web only developers, it's not. There's a lot of depth, performance, and control to be had there.

If you want to see what I'm talking about, get visual studio community edition (if you don't have visual studio already) and spend a weekend with WPF without XAML. I think you'll be surprised with how much fun you can have, and the level of control you can take. Make your own controls, override measure, arrange, and render.

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}"/>

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

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.

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

The world of JS / web "development". They are just now discovering that type system and compilers have advantages!

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.

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

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

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

Fwiw, the main motivation for the separation was for the IDE. It got easily confused mixing code and markup so we opted to keep them apart.

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.

> 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...

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...

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

https://github.com/Microsoft/PTVS/tree/6bf34d3611d34e94eddb6...

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).

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

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/blob/master/src/Common/Bui...

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.

What is the primary UI tech on Windows now?

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.

> 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...). This is mainly because they were already being actively implemented long before C++/CX became usable.

Thanks for the clarification.

Day to day, it's as often as not Win32 or it's thin .Net wrapper, WinForms.

WinForms is very productive but if you want high dpi support its hard work.

Unless one has Windows 10 Creators edition/.NET 4.7.

But then you might as well go down the UWP road, most of us still have to support Windows 7 or even earlier.

WPF is still the primary UI tech on Windows, UWP is built on top of it.

Anyone that knows their way around WPF, can make use of XAML, MVVM and all related UI concepts, regardless of the API differences between WPF, Silverlight, UWP and Xamarin.Forms.

For me they are all the same.

I know that UWP uses XAML and has very similar concepts, but is it really built upon WPF itself? I was under the impression it was it's own library/codebase.

It is its own implementation, but anyone that knowns one can use the other quite easily.

Most people don't seem to know this but WinRT/UWP XAML was actually a fork (not a rewrite) of Silverlight. Silverlight had a C++ core layer and a C# API layer, WinRT XAML kept the core and replaced the C# API layer with a new WinRT API layer.

> 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 ) 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/

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

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

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).

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.

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).

WPF came out in 2005 I seem to remember, they must have been developing it for several years before that. I don't think the HTML/CSS/JS thing had been settled on back then.

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

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/

Reply on news.ycombinator.com