[fendy3002]

My experience was from 2013ish so it may not be applicable here.

Best IDE and environment for C# is Visual Studio (not vs code) on windows. For me, C# is the best if you want to handle monetary transaction, due to it's native decimal data type. It is the worst to handle frontend (html) due to their static data types (cmiiw).

[PaulHoule]

Visual Studio is the way to go.

Decimal types are common in other languages like Java and Python.

Years and years ago I worked in a very sophisticated geospatial support application in C# with the back end in ASP.NET and the front end in Silverlight.

My take on ASP.NET was it had the most advanced templating system I ever saw but the mechanism used to make components (that look like an html element) that had both front end and back end behavior was terribly flawed because it was not compatible with what people call a ‘model view controller’ architecture which more importantly lets you decide which view to render based on what decision the controller makes from processing a form.

There was ‘ASP.NET MVC’ which was nothing special and threw the baby out with the bath water in that it didn’t support the really unique features of ASP.NET and was just another bad framework written by systems programmers who never coded up an application.

[fendy3002]

ASP.NET MVC isn't the best but it isn't the worst either. In my short experience with it around 2014ish, the default works well with /{controller}/{action} routes. But yes, the rendering engine still feels worse than PHP's twig or NodeJS's Nunjucks.

I imagine it's better to use ASP.Net MVC as rest api and use react on the front/client with Next JS.

[PaulHoule]

The strangest thing about .NET I think was the Windows Communication Framework which was ahead of its time in many ways but was hobbled by numerous choices that left it out of the mainstream.

A real long time ago (I think 2006) I was working on a web site product line that sold alcohol online. This is not fundamentally problematic (the delivery driver cards the recipient of the package) but you have to attend to details such as tax rates in various jurisdictions so we were shopping for APIs that would give us that information.

One vendor had an API that was pretty good but was based on SOAP and after two days of work I think I had solved the problem of making authenticated requests from PHP but there was still something broken, at that point we switched to a competitor that was using simpler technology and it working in less than 30 minutes.

I'd contrast that to the use of Jackson in Java backends where Jackson automatically generates a mapping between JSON and Java objects that "just works" most of the time and often you end up spending very little time thinking about serialization or being compatible with any popular clients. I'm sure ASP.NET has caught up, but I still think ASP.NET MVC would be overkill for the average backend for a React-like app. I have to admit that Sinatra-style JAXB in Java is so easy for that purpose.

[fendy3002]

Well, Microsoft things usually only works well with other Microsoft things only, and unreliable to outside techs (wcf, activeX). Better not use them if you aim for interoperability and stick to simple techs, even if you need to declare more classes that way.

> I'm sure ASP.NET has caught up, but I still think ASP.NET MVC would be overkill for the average backend for a React-like app.

I share the same idea, since I've found typescript (express) is usually enough for backend rest. But I cannot refute that C# is more reliable with it's variables than ts. Can't say much about Java though.