You might want to look at the UWP version of XAML. It has really useful things like compiled bindings (x:Bind), calling functions as part of a binding with automatic change detection of the function params (x:Bind only), x:Phase for progressive enhancement during scrolling, StateTriggers, and Setters for visual states (consolidated VisualStateManager and Triggers).
Not to mention the interop with the amazing Windows.UI.Composition API's, which let you do expression animations, Direct2D effects, lighting, parallax, backdrop brushes (e.g., blur the content behind an element), etc.
WPF's version of XAML feels quite dated now.
Also, doing layout on the UI thread is a severe perf limitation that currently affects all versions of XAML. Consider having the UI framework just specify constraints and letting the compositor/render thread compute the absolute positions ;)
Yeah UWP has a lot of good features but I always find when I go to it that it just lacks so many basics. It's like they kept building good stuff on top of Silverlight which stripped out a lot of useful stuff. Having said that I've not used it extensively (I had a good stab at Metro, but man that sucked) and ever since haven't gone back.
It's not x-plat either ;)
Obviously with Avalonia we have a long way to go (hence the Alpha) so we're getting the basics down first.
Layout on the UI thread is definitely a limitation too. I'd be interested to hear ideas as to how it could be done in a threaded manner.
UWP XAML has pretty much surpassed WPF with the latest SDK. There are some things missing, but the new features outweigh that and the performance is significantly better since it's all C++ and sits on top of DirectComposition instead of milcore. Many of the things that were removed (like FindAncestor bindings and DataContext inheritance) were done so for perf reasons or because they were refundant.
I'd use it as the basis for Avalonia instead of WPF. If only to have x:Bind instead of {Binding}, which thanks to function bindings removes a lot of ViewModel boilerplate.
I'm not on Win10 - are UWP apps still slow and clunky? Like they don't really act like normal windows? Still tablet-optimized or whatever? Last I checked on the W10 beta calc took several seconds to launch. (And had far less features, like no editable history.)
MS flubbed the launch and followup on Metro so hard (not to mention the shitware on the Store) it's really, really, turned me off from using or playing with it.
WinRT XAML is much faster than WPF ever was, it's just that they've started using it in very performance sensitive places where they never used any form of XAML before, like the calculator and start menu (the XAML calculator definitely doesn't take several seconds for me BTW, more like one second, but that's still too slow IMO), and it's still slower than the internal frameworks and bare Win32 calls they used to use. If they were WPF they'd be even slower.
I'm not super familiar with x:Bind, but based on what you're describing, it sounds like something that could be done in WPF (or, presumably, something that copies its design), as a markup extension. Fpr example (note wpf:Lambda):
Obviously this is still more verbose, because it is a converter on a binding (although it could be shortened further by providing a custom Binding-derived class, I think).
It's based on the XAML family of frameworks so lookless controls are probably the biggest differentiator between the frameworks you mentioned. Qt is C++, I've not tried any .Net bindings for it so I can't really compare. Xamarin uses native controls, which just a different approach really. Electron is great but you're embedding chromium in an OS window which doesn't work for everyone.
Does anyone have a prediction when .NET Core will be extended to include UI? I find this lack is the most confounding aspect of MSFTs strategy. Is Xamarin really it?
MSFT strategy is to develop a lightweight, cross-platform .NET runtime that can be hosted on Linux/Windows on Azure - that's where their ROI lies and where their .NET Core investments are focused. Their mobile/cloud approach is about using Xamarin to develop iOS/Android Apps that connect to backend Services hosted on Azure. Although they won't mind if you use Swift or Java to develop native iOS Apps or deploy on Linux - just as long as you host your backend Services on Azure.
There's very little incentive for them to invest in making a cross-platform Desktop UI, most x-plat UI's suck and requires significant resources and offer little return given the most popular UI's are either Web/Mobile - which they've already got covered.
I'd expect the most likely UI for .NET Core is to host a .NET Core runtime with a cross-platform web-based shell using something like Electron or CEF.
Microsoft acknowledged that using windows as a server is a big handicap for many companies. Making server-side .net components cross platform allows some to use their stack and maybe purchase other products like sql server.
However, the last thing microsoft wants is to make it possible for popular applications and games to run on other OSes. Hey, they need to sell you windows licenses.
19 comments
[ 3.4 ms ] story [ 46.8 ms ] threadNot to mention the interop with the amazing Windows.UI.Composition API's, which let you do expression animations, Direct2D effects, lighting, parallax, backdrop brushes (e.g., blur the content behind an element), etc.
WPF's version of XAML feels quite dated now.
Also, doing layout on the UI thread is a severe perf limitation that currently affects all versions of XAML. Consider having the UI framework just specify constraints and letting the compositor/render thread compute the absolute positions ;)
It's not x-plat either ;)
Obviously with Avalonia we have a long way to go (hence the Alpha) so we're getting the basics down first.
Layout on the UI thread is definitely a limitation too. I'd be interested to hear ideas as to how it could be done in a threaded manner.
I'd use it as the basis for Avalonia instead of WPF. If only to have x:Bind instead of {Binding}, which thanks to function bindings removes a lot of ViewModel boilerplate.
MS flubbed the launch and followup on Metro so hard (not to mention the shitware on the Store) it's really, really, turned me off from using or playing with it.
https://github.com/Microsoft/RTVS/blob/828b4e3919cbed507a4d0...
Obviously this is still more verbose, because it is a converter on a binding (although it could be shortened further by providing a custom Binding-derived class, I think).
How does it compare to Qt, Xamarin an Electron?
I doubt WPF is going to make a big comeback, though.
Thankfully there are still plenty of use cases not covered by web UIs.
There's very little incentive for them to invest in making a cross-platform Desktop UI, most x-plat UI's suck and requires significant resources and offer little return given the most popular UI's are either Web/Mobile - which they've already got covered.
I'd expect the most likely UI for .NET Core is to host a .NET Core runtime with a cross-platform web-based shell using something like Electron or CEF.
It is a standard .NET base that maps to and updates the ECMA standard in a portable way.
Anything else is supposed to be made available via NuGET packages.
Microsoft acknowledged that using windows as a server is a big handicap for many companies. Making server-side .net components cross platform allows some to use their stack and maybe purchase other products like sql server.
However, the last thing microsoft wants is to make it possible for popular applications and games to run on other OSes. Hey, they need to sell you windows licenses.