9 ms·

React: What WPF Should Have Been

55 points by yinso 9y ago

whowouldathunk 9y ago
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 9y ago
  It's not a "cool" JS "dev" nonsense name? What's the difference between flux and observer pattern?
ComputerGuru 9y ago
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 9y ago
  You can use Typescript with React (TSX instead of JSX) and benefit from static typing.
- mixedCase 9y ago
  Elm was among his examples, and the one he chose to demonstrate the vdom's viability when it comes to performance.
revelation 9y ago
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 9y ago
  > 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/ebfc4ca8bab234d453f15ee426af3b208f3c143c/Python/Product/Cookiecutter/View/CookiecutterSearchPage.xaml#L54 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/6bf34d3611d34e94eddb6388cfc5d100be70097e/Common/Tools/BuildTasks/ExtractLambdasFromXaml.cs 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/6bf34d3611d34e94eddb6388cfc5d100be70097e/Common/Product/SharedProject/Wpf/LambdaConverter 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).
  - m_fayer 9y ago
    This is brilliant and needs to be extracted into a library of its own. Thanks for surfacing this!
    - int_19h 9y ago
      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/Impl/LambdaConverter https://github.com/Microsoft/RTVS/tree/master/src/Common/Wpf... https://github.com/Microsoft/RTVS/blob/master/src/Common/BuildTasks/ExtractLambdasFromXaml.cs https://github.com/Microsoft/RTVS/blob/master/src/Common/Bui...
maxsilver 9y ago
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/create-a-hello-world-app-js-uwp https://docs.microsoft.com/en-us/windows/uwp/get-started/cre...
- dev360 9y ago
  > 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 9y ago
    Yes now they're known for monitoring your computer usage and updating it while you're not looking.
    - lucideer 9y ago
      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...
dev360 9y ago
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).
- tonyedgecombe 9y ago
  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.
- styfle 9y ago
  This was actually how I pitched it to my ASP.NET dev team: "React Components are WebControls for the front-end"
nightski 9y ago
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 9y ago
  What is the primary UI tech on Windows now?
  - pjmlp 9y ago
    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 9y ago
      > 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-cpp-template-library-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.
      - pjmlp 9y ago
        Thanks for the clarification.
  - 9y ago
c-smile 9y ago
> 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 9y ago
  So this is Electron before Electron existed? Does it have File IO APIs?
  - c-smile 9y ago
    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).
recursive 9y ago
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.
- 0xCMP 9y ago
  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.
- c-smile 9y ago
  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/visual.html 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.
m0ther 9y ago
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.
- mikewhy 9y ago
  Wouldn't that just be JavaScript?
  - m0ther 9y ago
    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.
- kitsunesoba 9y ago
  How flexible is this "sidestepping"? Could one build an implementation of another UI toolkit (like Cocoa) on top of it?
  - douche 9y ago
    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 9y ago
      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.
jarjoura 9y ago
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 9y ago
  > 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?
  - LeoNatan25 9y ago
    The world of JS / web "development". They are just now discovering that type system and compilers have advantages!
  - yazaddaruvala 9y ago
    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 9y ago
      VB6 just worked, too. In many ways, it worked better than the current conglomeration of web-dev technologies that replaced it.
jinushaun 9y ago
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.
vorotato 9y ago
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/

55 points by yinso 9y ago

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 9y ago
It's not a "cool" JS "dev" nonsense name? What's the difference between flux and observer pattern?

ComputerGuru 9y ago

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 9y ago
You can use Typescript with React (TSX instead of JSX) and benefit from static typing.
mixedCase 9y ago
Elm was among his examples, and the one he chose to demonstrate the vdom's viability when it comes to performance.

revelation 9y ago

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 9y ago
> 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/ebfc4ca8bab234d453f15ee426af3b208f3c143c/Python/Product/Cookiecutter/View/CookiecutterSearchPage.xaml#L54 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/6bf34d3611d34e94eddb6388cfc5d100be70097e/Common/Tools/BuildTasks/ExtractLambdasFromXaml.cs 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/6bf34d3611d34e94eddb6388cfc5d100be70097e/Common/Product/SharedProject/Wpf/LambdaConverter 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).
- m_fayer 9y ago
  This is brilliant and needs to be extracted into a library of its own. Thanks for surfacing this!
  - int_19h 9y ago
    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/Impl/LambdaConverter https://github.com/Microsoft/RTVS/tree/master/src/Common/Wpf... https://github.com/Microsoft/RTVS/blob/master/src/Common/BuildTasks/ExtractLambdasFromXaml.cs https://github.com/Microsoft/RTVS/blob/master/src/Common/Bui...

maxsilver 9y ago

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/create-a-hello-world-app-js-uwp https://docs.microsoft.com/en-us/windows/uwp/get-started/cre...

dev360 9y ago
> 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 9y ago
  Yes now they're known for monitoring your computer usage and updating it while you're not looking.
  - lucideer 9y ago
    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...

dev360 9y ago

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

tonyedgecombe 9y ago
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.
styfle 9y ago
This was actually how I pitched it to my ASP.NET dev team: "React Components are WebControls for the front-end"

nightski 9y ago

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 9y ago
What is the primary UI tech on Windows now?
- pjmlp 9y ago
  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 9y ago
    > 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-cpp-template-library-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.
    - pjmlp 9y ago
      Thanks for the clarification.
- 9y ago

c-smile 9y ago

> 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 9y ago
So this is Electron before Electron existed? Does it have File IO APIs?
- c-smile 9y ago
  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).

recursive 9y ago

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.

0xCMP 9y ago
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.
c-smile 9y ago
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/visual.html 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.

m0ther 9y ago

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.

mikewhy 9y ago
Wouldn't that just be JavaScript?
- m0ther 9y ago
  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.
kitsunesoba 9y ago
How flexible is this "sidestepping"? Could one build an implementation of another UI toolkit (like Cocoa) on top of it?
- douche 9y ago
  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 9y ago
    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.

jarjoura 9y ago

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 9y ago
> 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?
- LeoNatan25 9y ago
  The world of JS / web "development". They are just now discovering that type system and compilers have advantages!
- yazaddaruvala 9y ago
  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 9y ago
    VB6 just worked, too. In many ways, it worked better than the current conglomeration of web-dev technologies that replaced it.

jinushaun 9y ago

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.

vorotato 9y ago

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/