The article makes a good point but 90% of is irrelevant to a beginner. Open Visual Studio, pick your project type, and start coding.
Windows-only desktop app is the latest to confound me, let alone cross platform.
The .NET variants confused the hell out of me for the longest time until I just sat on Wikipedia and read the whole damn history, because every variant and version seems to be in play simultaneously
Heck, they've even brought over Winforms -- that technology is over 19 years old! So I honestly think using the term deprecated is too strong. They've done the right thing and continued to maintain multiple branches .NET until the newest version is fully finished and can reasonably replace the old one.
As I said in another comment, the framework you choose doesn't even matter that much. You're unlikely to even a notice a difference and changing from one to another is often as easily as selecting it from a drop-down (or editing a file) and recompiling.
So the framework to pick for a new application is... I don't know. Ideally the answer would be UWP with some kind of automated fallback for older windows, but its not. [0]
This windows UI confusion (3 different gui systems in play, when iterating over system settings) seems like a direct result of this framework confusion
[0] Apparently Win7 is still like 30% of the market, so it's hardly ignorable. https://www.digitaltrends.com/computing/windows-7-end-of-sup...
You just described all UI the frameworks, what replaces what, and what the limitations are! Microsoft also lays that out here: https://docs.microsoft.com/en-us/windows/apps/desktop/choose...
I've answered this question for myself: WPF. It's neither bleeding edge nor is it obsolete.
You can complain about the current state of things but I don't think there's any argument that Microsoft is doing the wrong thing here. They're iterating on their platform, making improvements, and supporting existing technology.
The problem is that all options lack some core fundamental expected feature. From that chart, WinForms lack High DPI awareness and customizable UI (tbh I'm not sure what customizable means here -- that custom controls/views are difficult or just skinning is difficult?), WPF also lacks High DPI and UWP lacks fallbacks (and a bunch of basic OS features like direct file access? I don't know why that's the case).
The differences between them aren't even trade-offs, so much as randomly incomplete. Granted, I haven't spent any time whatsoever trying workarounds -- maybe it's simple enough (WPF is clearly the least problematic, if DPI scaling can be worked around without much trouble). I've just been looking at the charts like that, and my ultimate answer is "???"
>You can complain about the current state of things but I don't think there's any argument that Microsoft is doing the wrong thing here
I think there is; Microsoft runs the .net ecosystem as its steward -- it intentionally creates, markets and governs pretty much every major framework and components that exists. For better or worse, the state of .net ecosystem is owned by Microsoft -- unlike say, rust, golang, python, c++, ruby, etc where the language maintainers are mostly divorced from the language ecosystem, and make no real say in the matter beyond broad recommendation of community-run frameworks (python is a little different, being batteries-included, but it's also well-known that stdlib is where libraries go to die; no one recommends python stdlib as best-in-class of anything). .NET is of course a non-closed ecosystem, and the community does contribute quite significantly, but nonetheless, if it's first-class it's almost always MS.
The current state of affairs is essentially a result of bad ownership; the high rate of churn in the javascript ecosystem can be blamed on the JS communities. The high rate of churn in the MS ecosystem can be blamed on MS. They've constructed a complex environment with unclear recommendations and continuous deprecation (fine, they're never actually deprecated because MS policy on backwards compatibility is second to none, but its "legacy"), a terribly confused naming convention and wide swath of overlapping technologies.
Don't get me wrong, MS does cool work, but they've made quite a mess, and it's quite clearly a result of constantly changing vision of how the .NET ecosystem should look like -- in combination with new projects seemingly forgetting MS's stance on backwards compatibility (nothing is ever just superseded; there must be an upgrade path or you will end up maintaining both forever [Unity has the same fundamental misunderstanding of their feature development]).
If there are going to be 4 UI frameworks, they should be competing on different models, APIs and mindsets (eg MVC vs MVVC vs MVU -- it's absurd that they're competing on core fundamental features instead). Although on the web-side of things, I think this is actually the case for .NET -- blazor vs MVC5 represent entirely different ways of approaching the problem. But AFAICT winforms vs UWP are really, from the programmer's perspective, the same thing. The underlying technology support changes (but in that case, you would ideally have the options be functionally complete).
Anyways as I said I've only been looking at it for the last year but that's my interpretation thus far -- the only way to understand the .NET ecosystem is to understand all the paths MS has taken, untaken, and re-routed. because their actual messaging and vision (as it connects to what they've implemented) is quite confused
WPF is system-DPI aware but it's not aware of per-monitor DPI as that feature didn't exist at all when WPF was conceived. I guess these days Microsoft doesn't consider that good enough to be called High DPI aware.
> I've just been looking at the charts like that, and my ultimate answer is "???"
I don't know -- I guess find it much less difficult than picking a web framework. The problem is that GUI frameworks (in any platform) are a complex mix of trade-offs. .NET and Windows is not the unique in this regard.
> The high rate of churn in the MS ecosystem can be blamed on MS.
I'm not sure you can call frameworks that have been around for multiple-decades a high rate of churn. The problems that Microsoft have is no different any of other platforms you've discussed. Yes, it's one organization but the problems are all the same. New developments require new framework but developers have lots of existing code. The fact that Winforms still exists is the same reason jQuery still exists.
Microsoft wanted everyone to move over to UWP -- this is kind of exactly what you're suggesting -- but developers just weren't interested. So they had to go back and take a more broad approach. But UWP is/was supposed to be the future.
> it's quite clearly a result of constantly changing vision of how the .NET ecosystem should look like
Not just the .NET ecosystem but the broader software industry as well. Many of the changes that Microsoft is making to .NET relate to changes made in mobile and on the web. As the world changes, .NET changes, and thus Microsoft maybe adds a new GUI framework to fit that world. Without that sort of change, we'd all still be using Winforms.
But I don't disagree. Microsoft has been in a long transition period to .NET core and they're finally started to come out the other side. With that done, there will be renewed effort to bring everything else together as well. I suspect in another couple of years this mess will be a lot more cleaned up. But I expect, unlike with other platforms, that most of my code written today will still work with whatever Microsoft comes up with in the future.
No data but from a lot of anecdotal experience I don't believe so - quite3e opposite.
I've never seen beginners (interns generally) or non-C# programmers (adept at other languages) come up to speed and start meaningfully contributing to projects on any other language other than C#.
With other languages (I've worked with) this just isn't true. I've never seen anyone but the most prodigious pick up C++, Java, JavaScript as quickly in professional contexts.
IMO C# is such an easy on-boarding languages that when hiring into C# teams it's not even a factor considering a candidates particular language experience.
As much as this is due to the language and well-organized libraries I think the tooling is just as much to thank. The dev experience in VS with a copy of ReSharper installed is unparalleled in software engineering.
It's pretty great until you tried out Rider :D, okay it's more or less the same as Resharper.
I'm not a Java developer, but i suppose IntelliJ will give you quite a similar development experience as Resharper/Rider?
As someone who did exactly this 25 years ago with VB, I really feel bad for new developers who don't have this nice experience and instead need to wrangle with half broken tools.
The experience is surprisingly good.
If you want to create and build + run a .NET web API, you just do:
"dotnet new webapi"
>cd into the directory
"dotnet run"