It's still relevant when MS decide to drop it and focus on yet another new shiny web-framework, like the 10 - or whatever number previous they've built - in the past 20 years. And, let's face it, they're not very good at it. If they were they wouldn't need to shelve so many previous attempts. Or, they decide to completely upend the entire ecosystem (Framework → Core) which then makes all previous web-frameworks (built by them) defunct.
Enterprises with sense would either roll their own, that they can then have complete control of forever, or try and find a framework that has staying power (although I realise even that is difficult).
I think running C# in the browser has benefits, for sure, but they should just stick to making that. And get out of the web-framework game for good to allow the community to create something exceptional - and, you know, play nice with others (other frameworks).
> When it comes to web, MS has been focused on ASP.NET since forever.
What's your definition of 'forever'? Are you talking about ASP, or ASP.NET, or ASP.NET Core? Or, Web Forms, MVC1, MVC2, MVC3, Silverlight, 'minimal APIs'? ...
Honestly, it's just one clusterfuck after another.
---
EDIT: There's a number of sub-comments here that seem to be missing the point. So, I'll expand here:
* For those who are questioning my right to have an opinion on this and doubting my expertise: I have used .NET since version 1. I founded a company in 2004 and have been responsible for building an enormous web-app product in the .NET world (since before jquery era, basically). I've seen all these frameworks come and go.
* For those who are saying "whatabout JS". Am I not allowed to have an opinion on the ever changing landscape of .NET web-app development without first criticising the 1000s of open-source developments?
* For those saying they've done migrations in the past. I'm pleased for you. Now try it with an application of over 500 pages when you have other things to be getting on with. Especially if you're not eager to jump to the latest and greatest every time a new one comes out, then you have a big problem of jumping multiple steps. Or, especially when they rip the entire ecosystem away (.NET Framework → .NET Core) meaning a big fix-up job for those migrating. I'd love to know what the collective economic impact of MS changing their minds every few years is.
But, finally, this is not about migration per se. This is about the poor quality of the frameworks themselves. Microsoft just follow the latest trends once they get going and then build half-assed versions that try to completely lock you into their world. They try to destroy everything that is the web so they can stop you leaving their ecosystem. This has profound problems for the consumer of these frameworks when MS drop it and go after something else. The Minimal APIs is a good example of bandwagon jumping, they've seen the trends to more functional-style APIs, and then they go and implement it in a horrible half-functional/half-OO ugly way. There are so many gaps in it due to its design that it's already obvious that it won't last (in its current form at least).
In 'JS land' it may not be the prettiest of ecosystems to work with, but JS written 20 years ago will probably still run today. Frameworks written 20 years ago can still be used. Support may go away, but that doesn't precipitate a rewriting of your UI layer. Anyone developing software for the long-term, which is professional software houses, should be wary of relying on anything MS build (outside of the language itself and its tooling, which is excellent).
Personally, I'd never bet the house on a MS web framework again. We ended up rolling our own, which was much more advanced than most web-frameworks (at the time) and stayed written (well, until .NET Core came along!).
A lot of these frameworks either composed together or had an upgrade path where it made sense. Plus if you're structuring your application right in .net, that web layer becomes another interface. I have taken an application across a few of those with some fuss, but you're covering 20+ years of development there.
The tooling ecosystem around JS is nuts. Packages (npm etc) hardly have any backward compatibility. You install a package today. In 3 months, that code won't build. The errors want you to go take a cryptography course to understand WTF is happening.
And I am not even talking about the language itself YET. ANd no, why should I be forced to use Typescript ? Yet another layer.
And I did I get to the 100s of config files that need to be set just so I can run "npm build" ? Webpack, Vite, blah blah.
> You install a package today. In 3 months, that code won't build.
Skill issue. Like I do that regularly. And I'm not even particularly great at frontend tech, so after 3 months I need to hit the docs to actually change anything. But the build pipeline works just fine.
> And I did I get to the 100s of config files that need to be set just so I can run "npm build" ?
..."webpack.config.ts", "package.json" and "package-lock.json" is not 100s. I mean I've seen places with, like, _a dozen_, but those folks could do the same to bash scripts and Python, some people are just messy about it.
Your way of upgrading front-end tech, where you need to hit the docs, sounds exactly like moving from the different .NET technologies to the latest version. I still tend to build out classic MVC applications, and use JavaScript only for progressive enhancement. I've been able to move from .NET Framework to the different versions of .NET Core, and now just .NET. I just follow the documentation, Microsoft has great documentation on how to upgrade. It just sounds like you are more familiar with working with front-end tech, and I would hazard a guess that you are actually much better at it than you either let on, or believe you are (Impostor syndrome, I get it all the time until it's crunch time, and then you just get things done).
I'm not trying to convince you to change technologies, but if you're familiar with a specific process, it's always going to be easier to follow that process than something you're not familiar with. This is coming from someone that still uses Grunt for their front-end build pipeline. It's not the newest, but it's still well supported, and I know it very well and can pull off a lot with it.
> Your way of upgrading front-end tech, where you need to hit the docs, sounds exactly like moving from the different .NET technologies to the latest version.
What front-end tech, everything is typescript.
Also not upgrading. I need to read the readme file because I didn't run the software in 3 months. Point is, it will _still run_. It might need a few updates for security reason, but it will _not_ magically stop working.
> It just sounds like you are more familiar with working with front-end tech,
No. I'm a full-stacker, but very much focused on backend, and actually mostly in Python. But nodejs + typescript actually works well enough that, even with _decades_ of Python experience, I now need a proper reason to pick it over typescript for a new thing.
> I'm not trying to convince you to change technologies, but if you're familiar with a specific process, it's always going to be easier to follow that process than something you're not familiar with.
Yep. Maybe the reason why some folks struggle so hard with running their old JS stacks, rather than some .net superiority?
Enterprises with sense would either roll their own, that they can then have complete control of forever, or try and find a framework that has staying power (although I realise even that is difficult).
I think running C# in the browser has benefits, for sure, but they should just stick to making that. And get out of the web-framework game for good to allow the community to create something exceptional - and, you know, play nice with others (other frameworks).