AKA mobile and Windows.
.Net is cross platform on mobile. Outside of it, if your project ever need to run in anything that isn't Windows, or communicate with anything that isn't Microsoft, then you can't use .Net. That makes it fit for enterprise CRUDs and not much else.
I mean it is honestly by far the best framework I've uses to communicate to everything from 40 year old hardware to modern web services and APIs.
As far as "run on anything that isn't windows" I'll grant you, that's a very emerging area, but you can run .net (or some flavor it) on a lot of different platforms.
Hell I've got a raspberryPi running windows 10 IOT with .net running on it, and it works like a top.
And statements like "If Microsoft doesn't pour a billion dollars into getting .Net ready for Linux in 2018, .Net is over." say's to me, you don't really have your finger on the pulse on the enterprise ecosystem at all.
You'll be hard pressed to find a language that has breadth and depth that .net has. Couple that with the new push to Open source, from an enterprise standpoint, it's a very attractive platform.
Windows 10 IOT is basically Raspberry Pi and Allwinner A64 only at this point, which excludes most of the ARM SBCs out there.
The problem with both these platforms is they are horribly I/O limited, to the tune of 1 full USB port worth of bandwidth. Other SBCs commonly push 4x that or more!
These programs can do anything, just like any other code in any other language, and the protocols (like HTTP or UDP) to talk between processes or programs have nothing to do with the code itself, which gets compiled down to the same machine level instructions anyway regardless of what language you use.
So what communication protocol are you using that .NET can't talk to? In Enterprise it's almost always SOAP or REST and .NET has some of if not the best technologies for producing or consuming both.
That's just plain wrong. Not only might .NET be a good option for a backend system (which can, of course, communicate with any platform), but people have been using .NET on non-windows systems via Mono for many years
With the emergence of AJAX though most competent WebForms developers dumped it because of then overheads and used the framework more like Classic ASP while integrating AJAX.
In retrospect, I'm not surprised MVC gained popularity so quickly.
The issues with FormState made it mostly unusable over the internet, it was relegated to intranet applications for the most part.
You meant stateful, right? I mean if we're being pedantic it's good to actually be correct.
Something that has success is successful, and when you're having trouble sleeping you might say you're feeling wakeful. Why then would it be state-full?
If you have a massive complex webapp then you should use MVC, or look at a separate frontend JS talking to a backend API, but WebForms serves its niche very well.
WebForms' selling point is that it is easy to bootstrap, but its limitations quickly become a liability in an enterprise setting, where small apps rarely stay small. Once you decide you need to extend your app and/or integrate with newer non-MS web technologies, you are backed into a corner.
WebForms is something that really ought to have been deprecated, but people are still clinging onto it because it's so easy to use and there are too many legacy apps that still depend on it.
I suspect it's the kind of Stockholm Syndrome that have kept Mongo users faithful over the years. At the back of your head you know you're going to have to pay down the technical debt later, but you can't resist because it's so easy to get started and to see results.
(though to be fair, Mongo 3.4 onwards has overcome some of the serious flaws of earlier versions)
.NET runs everything from desktop apps to web infrastructure to mobile games - it's a lot more encompassing than building some websites. It also integrates into a vast ecosystem with Office, SQL Server, Active Directory and is backed up by the fast-growing Azure Cloud. Most small, medium and 100% of the Fortune 500 run on .NET code and services.
HTTP/2 is just not part of Kestrel yet, which is the default new .NET Core web server. You can always use other libraries and this doesn't affect GRPC at all (which can easily generate the server from .proto stubs).
And how are the front-end wars over? Asp.net has great integration with all these modern JS frameworks, along with MVC and WebForms which are both still viable and used often. Why does there need to be a "niche" when .NET already does far more?
It seems like you found 1 missing feature and are proclaiming it a failure when the reality is that it's one of the most common frameworks today, and now also runs great on Linux. It'll be around for decades.