Recently I've been participating in a team discussion about whether or not to choose WPF as a framework for a new "greenfield" Windows-only applica...
For further actions, you may consider blocking this person and/or reporting abuse
I don't think it's of much worth trying to enumerate every available option, except for the mere purpose of being exhaustive. Most of them are there just because of history. If you want to go with "legacy" because of familiarity, then WPF and WinForms are the ones, you already know them. Otherwise, I think it's rather clear:
Of course some of these frameworks are in preview phase, but if you're starting now and planning for the mid-term they could be sensible choices.
Indeed, I listed some frameworks for completeness, but I'd add at least two strong contenders to your list:
Uno Platform. What they're doing is quite amazing, basically, C#/.NET/WinUI XAML for pixel-perfect UI that works on desktop, mobile and even web (via WASM).
Example: playground.platform.uno/#grid
Avalonia UI - mature and well supported.
Both are actively maintained and supported by consultancy business and active contributing communities built around them (unlike presently WPF).
I deliberately didn't include React Native because it isn't based on .NET stack (a prerequisite for this research), same as Flutter. The latter would probably be my personal choice if I needed a true cross-platform solution (not just Windows Desktop).
I was focusing on what Microsoft seems to suggest as alternatives (including Electron, even though there is nothing MS specific there, but you can always add some FAST fluent components...). Of course, Uno is great, but I didn't know about Avalonia, thanks for the suggestion!
I mostly see cosmetic, ported-from-4.8 fixes in the WPF repo. But even that is a good sign, it was mostly a GitHub bot updating dependencies a month ago, when I published this article.
NET 4.8 is still maintained with monthly service releases (and will be through 2029, IIRC). Apparently they're back-porting 4.8 WPF fixes to .NET 5/6. There are no new WPF features, and I imagine these fixes are largely driven by VS2022, which is still based on .NET 4.8.
BTW, FAST.design is fantastic, yet Microsoft uses Fluent UI for O365 HTML UI. Looks like there's a lot of internal competition inside Microsoft in the space of UI frameworks, but WPF isn't a part of it.
Office 365 uses React and its components probably predate FAST. There is a port of the office Fluent components to Blazor github.com/BlazorFluentUI/BlazorFl.... There is some interesting discussion regarding the relationship of Fluent UI components and FAST here github.com/dotnet/aspnetcore/issue.... That issue was closed after the creation of a new project with FAST wrappers for Blazor github.com/microsoft/fast-blazor.
Thanks! The discussion link is golden, I haven't come across it until now. A great read.
Regarding WPF, after reading your posts I checked their GitHub and I did find reasonable activity, at least for a mostly legacy framework it has a decent share of commits. Also there are a couple of maintained Metro/Fluent themes open source projects for a face-lift. Although I wouldn't go there for a green field project.
Tks, I just had another look at the WPF repo, commented above :)
I feel you :)
Thanks for article.
We have a huge application in WPF and I feel that WPF will not continue, due to its complexity in styling, the overall cumbersomeness, which is increasingly showing compared to other tools. I would appreciate if there was a way to convert a WPF application into anything that can live on. But this would only be possible in part, because no one can programmatically convert insanely complicated nested styles with its insane bindings in visual trees. I see the WPF as a trap today.
Glad you liked the article. Perhaps, the less drastic way to modernize a legacy WPF app would be to start converting it incrementally, view-by-view, to WinUI, using WinUI XAML islands. However, if you're really looking for something that would live on, and want to stay in .NET ecosystem, you may want to evaluate Blazor/Desktop. Historically, ASP.NET dev space has had a lot less friction than .NET UI dev space.
I also find this HN thread a relevant and interesting read.