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