5 ms·
> if they still want to be relevant in the non-enterprise web game They don’t. Microsoft makes products for companies who will pay for software.
by tatersolid 3y ago
> if they still want to be relevant in the non-enterprise web game
They don’t. Microsoft makes products for companies who will pay for software.
- bottlepalm 3y agoThey're losing a lot of business to Next.js/Remix/Svelte. If MS had a viable competitor based on .Net then more businesses might keep their IIS and Windows Server licenses. The Windows path leads businesses to SQL Server as well. I've seen this play out first hand.
- pjmlp 3y agoSadly can confirm, I have been working as polyglot dev for years, also a reason why I have so many opinions, never siloing under a specific XVYZ Developer label. Several CMS on the .NET ecosystem that relied on .NET for their plugins, when they went headless, decided to focus on supporting Next.js and friends for their UI component layer, removing Web Forms, MVC, Razor Pages support for these kind of workflows. Others, like Sitecore, decided that it was too much code to rewrite from .NET Framework to .NET Core, and not only refocused on Next.js with Vercel agreements, they also pivoted for an API first approach, and acquired non-.NET based products as means to evolve their product roadmap away from .NET. Myself, I have been involved in a couple of .NET Framework to Java migration projects, as given some of the stuff the customers would need to write from scratch in modern .NET, they decided it was the right time to move away from Microsoft stack on the server infrastructure. It should be noted that it isn't an accident that Microsoft, after all these years, has acquired jClarity and is now an OpenJDK contributor. Who have thought to see this kind of stuff a few years ago? https://devblogs.microsoft.com/java/ https://devblogs.microsoft.com/java/ https://www.theregister.com/2024/01/31/microsoft_seeks_rust_developers/ https://www.theregister.com/2024/01/31/microsoft_seeks_rust_...
- bottlepalm 3y agoMicrosoft fucked themselves hard having basically no upgrade path from legacy ASP.Net Framework to what there is now. It basically dead ended the large million line app that ran the company I worked for and forced a costly rewrite away from Microsoft. Though many parts of it still exist today, still on 4.8. For a company, Microsoft, that prizes backward compatibility and typically provides good upgrade paths, I felt very betrayed having trusted them as our platform.
- neonsunset 3y agoThe upgrade path to ASP.NET Core itself is the most straightforward out of everything that existed during .NET Framework days, a lot of code requires little to no changes and the code that requires a lot usually was questionably written in the first place or relies on problematic APIs.
- bottlepalm 3y agoWhat are you talking about? ASP .Net Framework versus Core is completely different. Not just rewritten the API is totally changed as well. Many libraries were completely removed - WebForms, OData 3, the entire bundling infrastructure, etc.. How requests are handled, and how you pre/post process requests is completely changed as well. Their documentation even says, "Updating an app from ASP.NET Framework to ASP.NET Core is non-trivial for the majority of production apps" Even that is an understatement. https://learn.microsoft.com/en-us/aspnet/core/migration/inc/overview https://learn.microsoft.com/en-us/aspnet/core/migration/inc/...
- neonsunset 3y agoIt was not trivial but the subjective experience matters a lot. In migrations that I participated in the most difficult parts were not related to ASP.NET but to third-party libraries. Another pain point at the time was moving off WCF which ended up being packaged up on some legacy Windows host as a separate microservice for just that purpose to not hold everything else back but that's it. Swapping out the startup and hosting models was not a challenge because the APIs were comparable, some controller classes had no lines changed either, and moving off IIS pool arguably is all around improvement (and far easier, to manage with docker and deployment manifests).