It’s amazing how much worse outlook got and how fast it got so much worse. It also can’t handle screens with different scales, it sometimes inexplicably fails to render an email, printing can produce files of different size - using the web version produces smaller pdfs than the desktop version. I miss thunderbird a lot since the company forced Outlook use and also removed the classic outlook option - or maybe it only has the weird white space version now.
My guess is if you build with .NET Framework you can just forever run your builds, but if your source code is based on newer .NET you have to update to a new version each year, and deal with all the work in upgrading your entire project, which also means everyone in your team is also upgrading their dev environment, and now you have new things in the language and the runtime to deal with, deprecation and all that. Plus lots of packages don’t update as fast when version changes occurs, so chances are you will probably take more work and use as few dependencies as possible if at all, which may cause a lot of work. Instead it’s best to, if you need to depend on something, to be a very big Swiss Army knife like thing.
I think node is just more flexible and unless .NET Framework like forever releases or much longer term support make a come back, there’s no good trade off from node, since you don’t even get more stability.
> if your source code is based on newer .NET you have to update to a new version each year
.NET has a really refreshingly sane release life cycle, similar to nodejs:
- There's a new major release every year (in November)
- Even numbers are LTS releases, and get 3 years of support/patches
- Odd numbers get 18 months of support/patches
This means if you target LTS, you have 2 years of support before the next LTS, and a full year overlap where both are supported. If you upgrade every release, you have at least 6 months of overlap
There's very few breaking changes between releases anyway, and it's often in infrastructure stuff (config, startup, project structure) as opposed to actual application code.
I think it's important to remember that Dotnet projects can use code built for older releases; to an almost absurd degree, and if you don't go to before the .NET Framework divide, you largely don't even need to change anything to move projects to newer frameworks. They largely just work.
The .Net platform is honestly the most stable it has ever been.
Recent experience report: I updated four of my team's five owned microservices to .net 10 over the past two weeks. All were previously on .net 8 or 9. The update was smooth: for the .net 9 services, I only had to update our base container images and the csproj target frameworks. For the .net 8 services, I also had to update the Mvc.Testing reference in their integration tests.
It's hard for me to imagine a version increment being much easier than this.
.NET Framework had back then, when it was not in frozen state as it is now, every release a list of breaking changes. Modern .NET breaking changes are not worth talking about. Keeping up with the state of the art however is more interesting... But that is needed to be a solution for today and to stay relevant.
AKA people who are willing to be honest about its faults. .NET has a lot of social commentary on how stable and robust it is yet for some reason in every project I've had the displeasure of brushing up against a .NET solution it's always "we're updating" and the update process magically takes longer than building the actual feature.
Or what is a pretty standard feature in other tech-stacks needs some bespoke solution that takes 3 dev cycles to implement... and of course there's going to be bugs.
And it's ALWAYS been this way. For some reason .NET has acolytes who have _always_ viewed .NET has the pinnacle of programming frameworks. .NET, Core, .NET framework, it doesn't matter.
You always get the same comments. For decades at the point.
Except the experience and outcomes don't match the claims.
Just before I get the reply, I'm pretty familiar with .NET since the 2000's.
Since the anabolic window is a lie and you have roughly 72 hours to feed yourself protein after effort you can skip breakfast without any impact if you don’t feel hungry. I don’t think many nocturnal people who wake up regularly at 10:00 really eat breakfast if lunch is 2 hours away, regardless of gym habits.
reply