I Rewrote WinUI to WPF(github.com)
github.com
I Rewrote WinUI to WPF
https://github.com/lepoco/wpfui
88 comments
Looks sharp! I've worked with WPF quite a bit in the past and still think it's the nicest UI framework from a developer perspective. How's the performance these days? Compared to plain Win32 applications, I remember it feeling very sluggish once your WPF application has a few dozen controls.
Really? I did about a year of it and I must admit it was not a fun year (~2014, so a while ago). Styles and binding were so overly verbose, and I felt like I was constantly fighting the tooling. The dev loop was horrible compared to anything related to building UIs for web apps. Interested in your experience and why you think it is a really nice UI framework from a developer perspective?
WPF was ahead of its time when it was released in 2006. It might have been the first to use data bindings and popularize the MVVM pattern. Web UI frameworks were barely in existence and webpages typically didn't have that desktop-y/SPA feel. WPF was king for a while until web took over.
Declarative data-binding wasn't anything new in WPF: it significantly postdates ASP.NET WebForms which had declarative data-binding, though, yes: the web doesn't count because web UIs aren't stateful in-memory on the server.
I feel MVVM is an anti-pattern: it necessitates long-lifed mutable instance state (the object of the class of your view-model) which is much harder to reason about (for example, try updating a bunch of properties in response to another property getting updating), but for me, the worst part is the inability to differentiate or identify the source or origin of new data that appear in a property setter: it's very difficult to determine if a TextBox TextChanged event came from a user-initiated action, was set by another method in the class - or was a knock-on property change - because a property setter doesn't have an EventArgs parameter. This can cause ViewModel event-handlers to get caught-up in infinite-loops or at the very least sending large amounts of inconsequential and unnecessary event-messages around and invoking (potentially expensive) property-setters and getters. I still agree that MVVM was a huge improvement over simply subclassing widgets and windows like we do in WinForms, VB6, Delphi, and JWT/Swing - but all MVVM brings you is separation between UI and Business/Domain in name-only; your ViewModels are still inevitably going to end-up with dozens of new properties bound to sone arbitrary presentational XAML attributes.
XAML alone is a decade past it’s time. It’s hugely verbose and is filled with so many gotchas (wanna bind a bool property to a control’s visible/hidden state? Not without an extra 50+ chars of binding params and value-converters). XAML also falls for the pitfall of assuming a GUI can always be modelled as a strict hierarchy of containers and controls.
Overall, XAML feels like what the Microsoft of the mid-to-late 1990s wanted to turn HTML into.
———
I hope I don't sound like another React fanboy (and I personally use Redux, not React)- and I'll argue that modelling state as a history of immutable, almost serialized, state trees is fantastic for so many things - especially typical database/business application work, but it's also utterly inappropriate for so many other kinds of applications (like, you wouldn't serialize the entire state of a raster image of HTML <canvas>, or re-run an append-only list of drawing instructions (like PostScript/Windows Metafile) for Canvas 2D context or even WebGL - BUT overall the Reflux/Redux/React design of a strict one-way flow of data and state brings so much clarity and makes it easy to see how different components (even in an abstract sense) interact with each other: they don't! It really does force you into a better way of thinking about program code, state and flow.
——
Not that it matters: Microsoft has completely dropped the ball on keeping the Win32 desktop dev-story alive. WinForms is uncool and terrible but there is no faster alternative for putting together a quick simple form in an EXE. If you use WPF you’d still be trying to get MahApps working,
-----
> Web UI frameworks were barely in existence and webpages typically didn't have that desktop-y/SPA feel. WPF was king for a while until web took over
2005-2006 was after the start of "Web 2.0" and after AJAX had been established - but mostly: when Firefox had already been out for 2-3 years and for that companies that were willing to go all-in on Firefox for their users, they really could have have desktop-quality SPAs made using Firefox's massively superior support for modern CSS techniques that IE6 had avoided for over 5 years at that point - can you imagine Google not releasing a Chrome update for 5 years?
So it was IE6's fault that better SPAs weren't around on the Internet - but it was also IE6's fault that so many companies had the 1990s near-equivalent of an SPA: ActiveX-heavy intranet sites that only worked in IE6. That point amuses me.
I feel MVVM is an anti-pattern: it necessitates long-lifed mutable instance state (the object of the class of your view-model) which is much harder to reason about (for example, try updating a bunch of properties in response to another property getting updating), but for me, the worst part is the inability to differentiate or identify the source or origin of new data that appear in a property setter: it's very difficult to determine if a TextBox TextChanged event came from a user-initiated action, was set by another method in the class - or was a knock-on property change - because a property setter doesn't have an EventArgs parameter. This can cause ViewModel event-handlers to get caught-up in infinite-loops or at the very least sending large amounts of inconsequential and unnecessary event-messages around and invoking (potentially expensive) property-setters and getters. I still agree that MVVM was a huge improvement over simply subclassing widgets and windows like we do in WinForms, VB6, Delphi, and JWT/Swing - but all MVVM brings you is separation between UI and Business/Domain in name-only; your ViewModels are still inevitably going to end-up with dozens of new properties bound to sone arbitrary presentational XAML attributes.
XAML alone is a decade past it’s time. It’s hugely verbose and is filled with so many gotchas (wanna bind a bool property to a control’s visible/hidden state? Not without an extra 50+ chars of binding params and value-converters). XAML also falls for the pitfall of assuming a GUI can always be modelled as a strict hierarchy of containers and controls.
Overall, XAML feels like what the Microsoft of the mid-to-late 1990s wanted to turn HTML into.
———
I hope I don't sound like another React fanboy (and I personally use Redux, not React)- and I'll argue that modelling state as a history of immutable, almost serialized, state trees is fantastic for so many things - especially typical database/business application work, but it's also utterly inappropriate for so many other kinds of applications (like, you wouldn't serialize the entire state of a raster image of HTML <canvas>, or re-run an append-only list of drawing instructions (like PostScript/Windows Metafile) for Canvas 2D context or even WebGL - BUT overall the Reflux/Redux/React design of a strict one-way flow of data and state brings so much clarity and makes it easy to see how different components (even in an abstract sense) interact with each other: they don't! It really does force you into a better way of thinking about program code, state and flow.
——
Not that it matters: Microsoft has completely dropped the ball on keeping the Win32 desktop dev-story alive. WinForms is uncool and terrible but there is no faster alternative for putting together a quick simple form in an EXE. If you use WPF you’d still be trying to get MahApps working,
-----
> Web UI frameworks were barely in existence and webpages typically didn't have that desktop-y/SPA feel. WPF was king for a while until web took over
2005-2006 was after the start of "Web 2.0" and after AJAX had been established - but mostly: when Firefox had already been out for 2-3 years and for that companies that were willing to go all-in on Firefox for their users, they really could have have desktop-quality SPAs made using Firefox's massively superior support for modern CSS techniques that IE6 had avoided for over 5 years at that point - can you imagine Google not releasing a Chrome update for 5 years?
So it was IE6's fault that better SPAs weren't around on the Internet - but it was also IE6's fault that so many companies had the 1990s near-equivalent of an SPA: ActiveX-heavy intranet sites that only worked in IE6. That point amuses me.
I co-sign everything here. Work with WPF as my day job (which I happen to love; great team, great company, great gig, not so great UI framework dependencies) so I feel the pain points daily.
MVVM is just hard to reason about and debug, especially with dodgy control implementations (more of an issue for UWP). It’s especially hard with converters and lack of great language tools. I also think the framework is in need of about 10 years of modernization that it just doesn’t get.
WPF (and MAUI and UWP and WinUI and UNO) would be so much better with:
- Razor for XAML: would obviate converters and a lot of other painful challenges
- Multiple styles for a single object; this is killer especially in a web context. It is really painful implementing web-oriented design systems in WPF. Tailwind for WPF would be amazing, but is more or less technologically impossible to implement due to framework limitations.
- Modern styles by default. WPF apps look bad out of the box. MS should make it easy to opt-in to a Windows 11 appearance, which this project proves is easily possible.
MVVM is just hard to reason about and debug, especially with dodgy control implementations (more of an issue for UWP). It’s especially hard with converters and lack of great language tools. I also think the framework is in need of about 10 years of modernization that it just doesn’t get.
WPF (and MAUI and UWP and WinUI and UNO) would be so much better with:
- Razor for XAML: would obviate converters and a lot of other painful challenges
- Multiple styles for a single object; this is killer especially in a web context. It is really painful implementing web-oriented design systems in WPF. Tailwind for WPF would be amazing, but is more or less technologically impossible to implement due to framework limitations.
- Modern styles by default. WPF apps look bad out of the box. MS should make it easy to opt-in to a Windows 11 appearance, which this project proves is easily possible.
>Razor for XAML
I sometimes wonder if it would be easier to skip the XAML altogether and build the object model in code.
I sometimes wonder if it would be easier to skip the XAML altogether and build the object model in code.
That's what I do in Forms, no XAML for me. Look at CSharpForMarkup lib that has extensions methods for Forms and now Uno to simplify coded UI's.
I seem to remember reading somewhere that the entire point of XAML and MVVM was to define a clean interface between the UI designer and the programmer. The programmer provides the view model classes and the UI designer can work on the XAML in Expression Blend without touching any code.
Microsoft believed that enough Fortune 500 companies would actually employ full-time UI designers to work visually in Expression Blend, who would seamlessly hand-off their visually-designed XAML to the implementation engs for data-binding and whatnot.
What a completely flat-out wrong expectation about the state of LoB apps. But even worse: after they saw no-one was using Blend they killed it off and made Windows 10’s default WPF look so awful, as if to retroactively punish anyone for using WPF at all.
What a completely flat-out wrong expectation about the state of LoB apps. But even worse: after they saw no-one was using Blend they killed it off and made Windows 10’s default WPF look so awful, as if to retroactively punish anyone for using WPF at all.
They didn't kill Expression Blend, they just moved it into Visual Studio. It still works in Visual Studio 2022.
> who would seamlessly hand-off their visually-designed XAML to the implementation engs for data-binding and whatnot.
true, that was a wrong approach for LoB apps. But this is a fairly typical for workflow what happens with end user web apps nowadays. People use something like Figma + React instead of Bend + WPF.
Maybe MS assumed that WPF would be commonly used for end user software. Instead the web invaded the desktop in the form of electron.
> who would seamlessly hand-off their visually-designed XAML to the implementation engs for data-binding and whatnot.
true, that was a wrong approach for LoB apps. But this is a fairly typical for workflow what happens with end user web apps nowadays. People use something like Figma + React instead of Bend + WPF.
Maybe MS assumed that WPF would be commonly used for end user software. Instead the web invaded the desktop in the form of electron.
Shhh... you're not supposed to say that, the emperor definitely has clothes on.
Razor for MAUI is available in the Experimental Blazor Mobile Bindings, but I doubt it will make the 7.0 cut. Having worked extensively with both XAML and Razor and Blazor, I can 100% guarantee that Razor + DI is 10x better than XAML.
I’m not convinced Blazor has staying-power.
Well said. WPF / MVVM does indeed have a lot of drawbacks and I could probably remember every single facepalm moment when I ran into the things You write about.
But where I beg to differ the WinForms bit. Fast as it may be, it's IMO way too conducive to people mixing UI / logic together and generally producing something that pleases the great Flying Spaghetti Monster, rather than any poor coder that has to maintain / bugfix said code.
In the end I guess it always boils down to "what's Your coding style and how well can You maintain discipline in it". WPF / MVVM, full of "gotchas" as it is, does at least one thing well : it gives newcomers a decent set of rules to begin with. Not particularly useful for a one-man project, but quite handy when there's a churn of developers in some bigger organization (my case).
But where I beg to differ the WinForms bit. Fast as it may be, it's IMO way too conducive to people mixing UI / logic together and generally producing something that pleases the great Flying Spaghetti Monster, rather than any poor coder that has to maintain / bugfix said code.
In the end I guess it always boils down to "what's Your coding style and how well can You maintain discipline in it". WPF / MVVM, full of "gotchas" as it is, does at least one thing well : it gives newcomers a decent set of rules to begin with. Not particularly useful for a one-man project, but quite handy when there's a churn of developers in some bigger organization (my case).
Hi, I'm a Redux maintainer. I'm always interested in hearing examples of Redux being used without React :) What are you using it for? Any particularly interesting problems you're solving with it, or pain points you've run into?
In .NET at least, I find the Redux design works better when Action objects are allowed to contain Delegates/Funcs to perform their state-mutation (state-progression?) instead of forcing a separation of Actions and Reducers.
Hmm. I realize that the .NET world is different than JS, but that _is_ an anti-pattern for Redux usage - separation of "what happened" from "how the state is updated" is absolutely intentional:
- https://redux.js.org/style-guide/style-guide#model-actions-a...
- https://redux.js.org/style-guide/style-guide#put-as-much-log...
- https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...
- https://redux.js.org/style-guide/style-guide#model-actions-a...
- https://redux.js.org/style-guide/style-guide#put-as-much-log...
- https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...
> separation of "what happened" from "how the state is updated" is absolutely intentional
In most projects I've worked on using Redux or Redux-style patterns (which, I'll admit is not a large number), keeping the separation didn't improve things, instead it added to more "fiddliness" and yo-yoing between files in the editor/IDE - this is especially the case when a project is iterating through changing project-requirements, especially for trivial actions/reducers. This only applies to cases where actions had a 1:1 mapping to reducers - and the bundled funcs were strictly pure-functions too, of course.
But I stress that I'm not a Redux expert (blame my lack of experience) so I appreciate that I almost certainly have done something wrong, so I'd love to be able to have a Redux expert on-call who I could just ping on Slack and pose a very domain-specific question to and ask "what is the Redux-way(TM) of doing this?" instead of having to try to go through the very abstractly written (often past the point of comprehension) pages of official documentation, blog articles and the like and hope I'm doing things correctly (especially in non-JavaScript environments).
----
Obviously the biggest barrier to the adoption of the Redux-pattern in non-JS environments is other languages' syntactical hostility to immutable objects, especially immutable object construction. In OOP-family languages like C#, Java, etc it really is a significant burden to have to both define primary constructors and the logic for reconstituting an entirely new state-graph for actions that only make 1 small, tiny deeply-nested change.... across multiple deeply-nested objects. The next major burden is the extra workload involved to change all of the above when project-requirements change regularly. There are also associated problems with having to normalize the state-graph and how to handle back-references (as true immutable objects cannot have back-references to parent objects unless you add another layer of wrappers over the state graph, and now you see the problem...!).
Also, remember that statically-typed languages are not going to get anything like JavaScript's spread-operator for a long, long time.
It sounds horrible (if not being complete heresy), but having state exposed as read-only to components/consumers, while allowing state mutation in-place by actions, does result in a drastic simplification of logic (I can't really call them "reducers" at this point), while you do lose the "free" Undo/Redo bonus you gain much faster performance. The important thing is the strictly one-way flow of data within the application, which is preserved, as is determinism: replaying the same actions from the same initial state will still result in the same end result state. (I'm not strongly advocating for the above, I'm just saying that to non-Redux-experts like myself, compromises can and do have perceivable value; after-all, we aren't all working on the official Facebook mobile app).
In most projects I've worked on using Redux or Redux-style patterns (which, I'll admit is not a large number), keeping the separation didn't improve things, instead it added to more "fiddliness" and yo-yoing between files in the editor/IDE - this is especially the case when a project is iterating through changing project-requirements, especially for trivial actions/reducers. This only applies to cases where actions had a 1:1 mapping to reducers - and the bundled funcs were strictly pure-functions too, of course.
But I stress that I'm not a Redux expert (blame my lack of experience) so I appreciate that I almost certainly have done something wrong, so I'd love to be able to have a Redux expert on-call who I could just ping on Slack and pose a very domain-specific question to and ask "what is the Redux-way(TM) of doing this?" instead of having to try to go through the very abstractly written (often past the point of comprehension) pages of official documentation, blog articles and the like and hope I'm doing things correctly (especially in non-JavaScript environments).
----
Obviously the biggest barrier to the adoption of the Redux-pattern in non-JS environments is other languages' syntactical hostility to immutable objects, especially immutable object construction. In OOP-family languages like C#, Java, etc it really is a significant burden to have to both define primary constructors and the logic for reconstituting an entirely new state-graph for actions that only make 1 small, tiny deeply-nested change.... across multiple deeply-nested objects. The next major burden is the extra workload involved to change all of the above when project-requirements change regularly. There are also associated problems with having to normalize the state-graph and how to handle back-references (as true immutable objects cannot have back-references to parent objects unless you add another layer of wrappers over the state graph, and now you see the problem...!).
Also, remember that statically-typed languages are not going to get anything like JavaScript's spread-operator for a long, long time.
It sounds horrible (if not being complete heresy), but having state exposed as read-only to components/consumers, while allowing state mutation in-place by actions, does result in a drastic simplification of logic (I can't really call them "reducers" at this point), while you do lose the "free" Undo/Redo bonus you gain much faster performance. The important thing is the strictly one-way flow of data within the application, which is preserved, as is determinism: replaying the same actions from the same initial state will still result in the same end result state. (I'm not strongly advocating for the above, I'm just saying that to non-Redux-experts like myself, compromises can and do have perceivable value; after-all, we aren't all working on the official Facebook mobile app).
Xaml != WPF. In Xamarin Forms land that property is a bool. We have `bool IsVisible`.
The problem is the design, and that will change over time as the various flavours of Xaml are supposedly on a path to converge.
The problem is the design, and that will change over time as the various flavours of Xaml are supposedly on a path to converge.
I remember I knocked out a fairly complex app in about two weeks in WPF. At the time such velocity wouldn't be possible in any other framework. The project continued for longer, but when words got out that WPF will be abandoned we decided to move to another platform, not as nice. It's a shame.
I was hoping that Microsoft would make it multi-platform, as it was the best system so far I worked with.
What's a source for WPF being abandoned? Limited new feature development aside, it was just ported to .NET Core.
I never felt verboseness to be a problem. But WPF styles are not the hot mess CSS is.
It’s still slow to start up. That’s partially because of .NET in general. There is a lot of code to read and JIT before a .NET application runs.
I think that's only partially right.
.NET apps can be published with AOT code (ReadyToRun). WPF apps are still pretty slow to launch with ReadyToRun enabled; I haven't profiled it to see why, but I suspect it has a lot more to do with WPF (somewhat abandoned for a decade, and the XAML bits have always been slow) than .NET.
In my experience the JIT penalty at startup isn't as bad as people think, the .NET JIT compiler is really fast and the average console app is very quick to start up.
.NET apps can be published with AOT code (ReadyToRun). WPF apps are still pretty slow to launch with ReadyToRun enabled; I haven't profiled it to see why, but I suspect it has a lot more to do with WPF (somewhat abandoned for a decade, and the XAML bits have always been slow) than .NET.
In my experience the JIT penalty at startup isn't as bad as people think, the .NET JIT compiler is really fast and the average console app is very quick to start up.
You're like 5 years behind, .Net has been snappy for years since core released.
What's a snappy .net app ? The few ones I know definitely feel slower than e.g. Qt apps
Paint.NET is probably the best example of a good, fast widely used .NET app.
That's the first example of "not fast" that came to my mind actually.
Seriously? The effort Rick puts into Paint.NET performance is unreal (check out his Twitter sometime). I've found it to be impressively fast, especially for how much functionality it has.
FWIW it was only recently migrated to a modern .NET version, give the latest version a spin if you haven't already.
FWIW it was only recently migrated to a modern .NET version, give the latest version a spin if you haven't already.
Paint.NET is a good example for how much effort it takes to develop a .NET app that has decent performance especially once it is a little bit complex
Just because it's impressive doesn't mean it's not slower than other systems. It's not mutually exclusive.
Agreed. Rick’s work on Paint.NET is just so impressive.
More like hardware is now hiding the .Nets overheads
No, both have gotten much faster. This is just one release of performance improvements:
https://devblogs.microsoft.com/dotnet/performance-improvemen...
It is worth noting that WPF can run on this latest version of .NET
It is worth noting that WPF can run on this latest version of .NET
“Snappy” is subjective. It definitely has improved But it’s still far away from what you could do with Win32 or MFC.
.Net != .Net Core, even though they rebranded it as such.
That's just revisionist marketing
That's just revisionist marketing
As a WPF developer, is it really modern though? Everyday at work I feel like I’m on the Titanic. Well built, well designed, but sinking.
I have never really understood what 'modern' means whenever someone shows their new library / framework / tool.
We're mostly just re-hashing ideas from the 60s and the 70s anyway.
I think modern simply means "similar to what big tech does". So those ugly characters with big arms and small heads? Modern. Flat design? Modern. Is it good? Who cares, it's modern.
When it comes to GUI it looks like we are slowly converging back to Windows 3.1 in terms of visual and programming style. Is it modern?
We're mostly just re-hashing ideas from the 60s and the 70s anyway.
I think modern simply means "similar to what big tech does". So those ugly characters with big arms and small heads? Modern. Flat design? Modern. Is it good? Who cares, it's modern.
When it comes to GUI it looks like we are slowly converging back to Windows 3.1 in terms of visual and programming style. Is it modern?
Win 3.1 shipped with zero-effort dark mode, so maybe a bit before windows 3.1 =)
You of course could switch color schemes easily.
But a lot of apps ignored them, wholly or partially, and just hard-coded colors. Try it with e.g. MS Word 6.
But a lot of apps ignored them, wholly or partially, and just hard-coded colors. Try it with e.g. MS Word 6.
I find that as time passes, more and more apps are custom rendered and don't use system color settings. Peak support was way back in the nineties.
Peak support seems to be around the platinum/CDE time where everything was just happy to finally have consistent sets of widgets to work with.
Whatever this style is, it is very ugly. I miss the old days of lovingly crafted pixel-art skeumorphism - even videogames rarely bother anymore.
> I have never really understood what 'modern' means whenever someone shows their new library / framework / tool.
It means they think it can do modern web api stuff without having huge issues.
It also signals that the speaker thinks others would make a similar choice in the future, for a dev tool etc., hoping for network effect . community familiarity and support.
It means they think it can do modern web api stuff without having huge issues.
It also signals that the speaker thinks others would make a similar choice in the future, for a dev tool etc., hoping for network effect . community familiarity and support.
> I have never really understood what 'modern' means
Well, to me that means things from the 1980s, when those ideas from 1960S and 1970s got sorted out and we got systems like St-80 with a small numbers of pervasive concepts, universally applied.
Then you got the postmodern period of Perl and friends...
Well, to me that means things from the 1980s, when those ideas from 1960S and 1970s got sorted out and we got systems like St-80 with a small numbers of pervasive concepts, universally applied.
Then you got the postmodern period of Perl and friends...
Vintage is modern by definition. :D
How is it sinking, though? It's not getting improvements, but that's a very different thing.
It's a similar thing IMO. WPF is understaffed to the point where it might as well be dead in my mind.
It hasn't received major new features in a decade. It's currently owned by the Windows team (not the .NET team) and they have staffed it with a skeleton crew. They don't even have bandwidth to review most community PRs.
Even the .NET team doesn't get responses to issues they raise on the WPF repo: https://github.com/dotnet/wpf/issues/3811
Adding to all that, WPF has a massive dependency on C++/CLI which means it cannot take advantage of many new .NET features until that is rewritten. And from what I can tell (from the outside) that will never happen.
It hasn't received major new features in a decade. It's currently owned by the Windows team (not the .NET team) and they have staffed it with a skeleton crew. They don't even have bandwidth to review most community PRs.
Even the .NET team doesn't get responses to issues they raise on the WPF repo: https://github.com/dotnet/wpf/issues/3811
Adding to all that, WPF has a massive dependency on C++/CLI which means it cannot take advantage of many new .NET features until that is rewritten. And from what I can tell (from the outside) that will never happen.
This is all true, but the framework doesn't just stop working because of that, and the tooling continues to support it. Hell, even WinForms is still chugging along, remaining a valid way to write desktop apps for Windows - and it has been in similar limbo for much longer.
Hmm, I wouldn’t say WinForms is in a similar limbo right now. It's maintained by the .NET team and it gets more attention than WPF. Work is happening to make WinForms compatible with NativeAOT and trimming, I think it will land in .NET 7 or 8.
(but yes, true, WPF still works and it gets enough support to keep it limping along)
(but yes, true, WPF still works and it gets enough support to keep it limping along)
Yeah, but like WPF, very little companies are writing promising new software using WinForms. I stripped my resume of anything WinForm related because I kept getting god damn DoD legacy-ware jobs.
At least C++/CLI isn't like the C++/WinRT dependency on WinUI/UWP.
Editing IDL files without VS tooling just like in the good old COM days pre-.NET, lovely.
Editing IDL files without VS tooling just like in the good old COM days pre-.NET, lovely.
Adding to what ripley said, there's never been a great (FOSS) ecosystem of WPF libraries. By now half of them haven't been updated since 2012 and half of those have bugs if you try to use them in .NET 5+.
It's not surprising, Microsoft seemed to abandon it at birth. If Microsoft can't be bothered then why should anybody else.
Visual Studio still has large parts of its UI written in WPF.
That's a good example. Where is the property grid in WPF, a component that is central to Visual Studio's UI.
Visual Studio has bits and pieces written in pretty much all UI frameworks that Microsoft ever had - at some point there were even HTAs there, not sure if that's still the case. Some bits get rewritten, like the main window chrome / menus / toolbars (all WPF now). Some do not. That said, as I recall, the property editor that you get when editing WPF controls and forms is itself WPF these days.
But anyway, my point is that it was hardly "abandoned at birth", given that WPF was originally released with .NET 3.0 in 2006, while the first version of VS to get WPF UI was VS 2010 - and more was rewritten since then. Even if no new VS components are ever going to be written in it, maintaining the existing ones makes it necessary to maintain WPF to some bare minimum standard.
(The same goes for WinForms and other UI stacks that VS still uses in places.)
But anyway, my point is that it was hardly "abandoned at birth", given that WPF was originally released with .NET 3.0 in 2006, while the first version of VS to get WPF UI was VS 2010 - and more was rewritten since then. Even if no new VS components are ever going to be written in it, maintaining the existing ones makes it necessary to maintain WPF to some bare minimum standard.
(The same goes for WinForms and other UI stacks that VS still uses in places.)
Visual Studio might well have used it but the point was what happened to WPF since it was released. Almost nothing. It wasn't complete when it was launched and has never really been updated in a significant way.
Have you seen Uno Platform?
It ports WinUI to iOS, Android, WebAssembly, macOS, and Linux.
https://github.com/unoplatform/uno
It ports WinUI to iOS, Android, WebAssembly, macOS, and Linux.
https://github.com/unoplatform/uno
Recent release/discussion:
"Uno platform 4":
https://news.ycombinator.com/item?id=29405909
Tbh, it looks like another "worse than freepascal / Delphi" solution... But maybe I've just given up on gui-stacks.
"Uno platform 4":
https://news.ycombinator.com/item?id=29405909
Tbh, it looks like another "worse than freepascal / Delphi" solution... But maybe I've just given up on gui-stacks.
But then you'd have WinUI in even more places where it doesn't fit. Why would someone footgun themselves like that? I get that some people might personally like it but it's going to be 'the odd one out' at best.
While I admire the work that goes into things like this I can't help to find the look of WinUI to feel like "yet another random Electron app". It's so in-between of everything that it doesn't really fit anywhere, except maybe one of the 2005 convertible laptops that can take a tablet UI and still make you use a keyboard and mouse...
Alternatively you can use WinUI within a WPF app using XAML Islands. Enables you to incrementally migrate away from WPF towards a WinUI 3-based app.
Down that path lies madness. Everyone I know who works with XAML Islands despises it. MS doesn't really push it because it's very broken.
Starting any GUI app development on Windows is very frustrating right now.. Winforms (dead, ugly), WPF (nearly dead), UWP (deprecated), WinUI2 (deprecated), WinUI 3 (buggy, maybe in a year), .NET MAUI (also immature).
> Winforms (dead, ugly)
Dead? Nonsense. WinForms is the most used technology/framework in 2021 for desktop GUI applications according to jetbrains.
https://www.jetbrains.com/lp/devecosystem-2021/csharp/
Also: https://blog.submain.com/death-winforms-greatly-exaggerated/
Dead? Nonsense. WinForms is the most used technology/framework in 2021 for desktop GUI applications according to jetbrains.
https://www.jetbrains.com/lp/devecosystem-2021/csharp/
Also: https://blog.submain.com/death-winforms-greatly-exaggerated/
Dead and ugly are both kind of vague terms open for debate so I'm not arguing your main point here (and I'm not the person you responded to) ...
... but as someone who did a lot of Win32/UI App programming back in the late 1990s and early 2000s (up to and including early WinForms), I recently looked through the landscape of available UI toolkits and can confirm that as someone who hasn't been keeping up with this stuff for years its INCREDIBLY confusing as to what technology you should build new projects on looking through the graveyard of half abandoned aborted starts Microsoft seems to have made from back then until now, with almost everything being officially deprecated or early access/unfinished.
The fact that WinForms might still be the best solution for starting a new project on is more of a condemnation of Microsoft's combined efforts in this area than it is something to be celebrated, IMO.
... but as someone who did a lot of Win32/UI App programming back in the late 1990s and early 2000s (up to and including early WinForms), I recently looked through the landscape of available UI toolkits and can confirm that as someone who hasn't been keeping up with this stuff for years its INCREDIBLY confusing as to what technology you should build new projects on looking through the graveyard of half abandoned aborted starts Microsoft seems to have made from back then until now, with almost everything being officially deprecated or early access/unfinished.
The fact that WinForms might still be the best solution for starting a new project on is more of a condemnation of Microsoft's combined efforts in this area than it is something to be celebrated, IMO.
Imagine the confusion of someone frozen in cryo around 2006 waking up now: Wait, that C# wrapper for Win32 is the recommended MS GUI framework? What went wrong?!
Not only that, but wrapping a deprecated framework at that... and then all the stuff that came in between. It's almost as if we're back at square one.
Yeah, it's a mess.
Personally I think web UI via WebView2 is the only way forward; Chromium is far and away the most powerful UI framework shipping with Windows these days. Even if "native" UI frameworks were doing everything right, it's hard to compete with all the investments in Chromium.
P.S. WinForms isn't dead; it's maintained by the .NET team and it gets a lot more attention than WPF. But, well, it's WinForms :)
Personally I think web UI via WebView2 is the only way forward; Chromium is far and away the most powerful UI framework shipping with Windows these days. Even if "native" UI frameworks were doing everything right, it's hard to compete with all the investments in Chromium.
P.S. WinForms isn't dead; it's maintained by the .NET team and it gets a lot more attention than WPF. But, well, it's WinForms :)
Not to mention they change the aesthetic of the operating system seemingly ever 2 years.
I still think Microsoft's best UI framework is the one they never promoted nor supported, WTL. It's just a shame about the C++ part.
https://en.wikipedia.org/wiki/Windows_Template_Library
https://en.wikipedia.org/wiki/Windows_Template_Library
Add to the mess that for some stuff we are expected to add C++ to the mix, and C++/WinRT tooling is like going back to the good old ATL days in Visual C++ 6.0.
Did you try https://avaloniaui.net/ ?
I built an awesome WPF note-taking/ idea aggregation app. Any idea how I can get it some exposure?
Reddit, Show HN, Producthunt, alternativeto.net
Yes, but I can't pass around an .exe nor am I willing to allow open builds from source, so maybe.....a YouTube video? Seems HN would downvote a Yt link, favoring interactivity. What do?
Set up a github pages blog with screenshots, a brief description and a download link. Then post it on Show HN! I try out nearly every note taking app posted there. (Though a Windows-only one might be difficult to...)
Distribute through ms store?
https://developer.microsoft.com/en-gb/microsoft-store/overvi...
(although I couldn't find an actual tutorial on "I have an exe, how can I publish in store" - it should support legacy (non uwp) apps now).
I'm sure someone here will have actual experience doing this..?
https://developer.microsoft.com/en-gb/microsoft-store/overvi...
(although I couldn't find an actual tutorial on "I have an exe, how can I publish in store" - it should support legacy (non uwp) apps now).
I'm sure someone here will have actual experience doing this..?
Just publish to Windows Store.