Comment by manigandham | Hacker News Reader

Comment by manigandham | Hacker News Reader

Parent Full thread

It's definitely not dead.

.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.

> everything from desktop apps to web infrastructure to mobile games

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'm not really sure what you mean by "Communicate with anything that isn't Microsoft, then you can't use .Net" I've used .net to communicate to vast array of non-microsoft products, serial over usb, shared pipes, com-interop, services, message buses, webapi etc..

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.

Compared to Python, serial in C# is quite a bit more annoying to handle. Esp. at those speeds, easier to write it all in Python and call it a day.

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!

> then you can't use .Net

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

.NET core runs on Linux, OSx and Windows. I would say that is about as cross platform as it gets.

> 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.

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 is a bit strong. I’m running an ASP.NET Cote app on Linux (well, SmartOS Linux emulation) with a PostgreSQL database and it works just fine.

I dont think you know what .NET is - it's an entire software platform comprising of several languages (C#,F#,VB) along with a compiler toolchain (Roslyn,RyuJIT), managed runtime (CLR), high quality standard libraries (.NET standard/BCL), and productive application frameworks (ASP.NET), that compile into programs that can now run on Windows, Mac, Linux, mobile phones and even Raspberry Pi's.

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.

I would find it hard to believe any new Projects would still use webforms. The fake statfull web MS tried to create with WebForms is just too bloated. With MVC they have something great, something you’d have to use generic handlers for in the past to get any sort of performance.

I'm a consultant and work across a number of accounts. Not sure what "fake statfull web" (assuming you meant state-full) means to you, but in one huge healthcare org and two medium-sized fin. services co's 4 new WebForms projects have started in the last 6 months. Smallest project is worth $1.2mm.

WebForms was meant to loosely mimic WinForms and provide an easy transition for VB developers from desktop to Web, and it was mostly successful. The fake statefullness OP's referring to is FormState and the attempts to make WebForms more like WinForms.

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.

To be fair, FormState problems could get pretty bad. By default, large apps would be posting back several hundred KB on each click (sometimes even in the low MB range). With AJAX, it was better, but still not in the acceptable range for non-intranet apps. There were always mechanisms by which competent developers could work around these problems, but for the most part, those would mean that you're fighting with the framework and not working in a particularly idiomatic, WebForms-y way.

In retrospect, I'm not surprised MVC gained popularity so quickly.

WebForms was a beast and a horrible web technology for the web. I was just stating that, since MS intent on killing VB, it was intended to make transition from Enterprise VB Desktop apps to Enterprise Web Apps easier and in that regard it was successful.

The issues with FormState made it mostly unusable over the internet, it was relegated to intranet applications for the most part.

>state-full

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?

I think it's different in Europe (where you appear to be located), but at least in the States Webforms are huge amongst the Fortune 500 and healthcare industries.

It's pretty awful in about any regard in my experience. What would be the reason to use it over MVC?

Isn't using WebForms faster for implementing intranet apps? Drag and drop stuff, done.

It can be for simple stuff. It can also be a huge pain in the ass and it took a while before it was truly JavaScript and AJAX friendly.

WebForms are still actively developed and supported by Microsoft. The latest version is very good and the WebForms paradigm is incredibly productive for general business-line apps. You can build entire apps within hours or days that would take months otherwise with separate frameworks.

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 is only good for the simplest of LOB apps. Yes it is still supported, but many organizations are discouraging its use in new applications due to difficulties in scaling and long-term maintenance. In my company, all new projects are required to use MVC.

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)

Reply on news.ycombinator.com