Live data from Hacker News

Performance Improvements in .NET 6

devblogs.microsoft.com

211–220 of 256 posts

Re: Performance Improvements in .NET 6

#211
post #69
post #30

Earlier quoted context omitted.

> It’s way worse than React in this regard (if not only by its sheer size and larger scope) FWIW, I've used React for 18 months now. Except Java and classic core PHP it is one of the most stable platforms I've developed on. So, in my view being less stable than React isn't a big problem.

I agree, React itself can be remarkably stable because they found the right abstractions early on and have been able to evolve just small variations of those central patterns over time. All the stuff people expect to use around react, on the other hand. That sees huge amounts of churn.

Luckily, if you can get everyone to accept it you can often manage just fine without.

I'm lucky to be on a team that agreed that redux etc wasn't necessary somewhere before I arrived, and coming from other places that insisted on latest fads it has been blissful.

Re: Performance Improvements in .NET 6

#212

At work, I'm the maintainer of a 30k SLOC VB.NET codebase. Originally windows-only, when I took over I ran it under mono on Linux and OSX. The day that MS released dotnetcore, I jumped to that. Overall the experience has been really good. There are lots of complexities, but in short... .NET 5 gave it a 4% speed boost across the board, going up to 20% [!] in some cases. Mainly that was ascribable to the intersection o…

I think it's really cool to see a successful example of modernizing a VB.NET codebase so that it too can play with the cool kids. I never really understood the disdain for VB.NET in the developer community, since the language has all kinds of neat little tricks up its sleeve. Kudos for pushing the counter-narrative.

Re: Performance Improvements in .NET 6

#213
post #39

WinForms and its Visual Studio designer are still broken, WPF is still riddled with bugs and was declared obsolete in ~2017 in favor of UWP, UWP is marked obsolete in favor of WinUI, and WinUI's OSS release was postponed just two days ago because it's not ready. Microsoft is marketing .NET 6 as the replacement for .NET Framework but you still cannot properly do desktop UI with it. I honestly don't understand why they…

It's all about Azure now, which makes for an emphasis on server- side capabilities.

Re: Performance Improvements in .NET 6

#214
post #78

Earlier quoted context omitted.

The UI story on Windows is completely broken but that has been the case forever. Has MS basically released anything sustainable on the UI side since MFC? It feels like they’ve constantly provided a new new replacement every few years that replaced the new replacement from a few years ago since then.

> Has MS basically released anything sustainable on the UI side since MFC? MFC is nothing more that a C++ GUI library wrapping the Windows Win32 GUI layer. The problem with that Win32 GUI is it has not changed for several decades, which is why any application using that Windows GUI layer looks old and outdated on modern Windows. Since Microsoft is not updating the Win32 GUI layer, it is basically obsolete. However so…

MFC was kind of a weird beast in general. In some ways it was just a C++ GUI API for Win32, but it did have distinct traits and behaviors that have MFC apps a subtle feel that many found unappealing.

Re: Performance Improvements in .NET 6

#215

My favorite part of dotnet 6 is the focus on hot reloading not mentioned here. Being able to work on a webapp that rapidly reloads in under a second is huge. It allows me to maintain the state of flow as I'm bringing something to life. I had a unique use case wherein I had a separate worker thread that also needed reloading with the hotreload. I was able to hook into the hot reloading via "[assembly: System.Reflectio…

Everything old is new again. ;-)

Re: Performance Improvements in .NET 6

#216
post #45

My favorite part of dotnet 6 is the focus on hot reloading not mentioned here. Being able to work on a webapp that rapidly reloads in under a second is huge. It allows me to maintain the state of flow as I'm bringing something to life. I had a unique use case wherein I had a separate worker thread that also needed reloading with the hotreload. I was able to hook into the hot reloading via "[assembly: System.Reflectio…

Even .NET Framework supports this in a limited fashion. Start an application in Visual Studio with a debugger attached, break at a breakpoint, change a line, save, and continue with the new code. No application restart necessary.

Not since async was added. You can’t make changes to any async methods because they haven’t figured out how to update the state machine.

Re: Performance Improvements in .NET 6

#217

On the topic of WPF apps in .NET core: Can anyone who has successfully migrated WPF apps to .NET core, in production, chime in on what was the experience like? Any major pitfalls or pros/cons to consider? I have a prospective client, running a WPF app in a soon to be deprecated windows embedded machine. They have a lot of domain knowledge in the app so are unwilling to re-write or port. I was thinking if it is feasib…

The resulting binaries are huge if you publish self-contained. If you don’t, you’ll need to include the redistributable installer so it’s still huge. Tree shaking is still in its primacy.

Re: Performance Improvements in .NET 6

#218

Earlier quoted context omitted.

When I was using it, all documentation samples (and nearly all other resources) were for XAML which made it unnecessarily hard to use API in pure C#. IMO, UI development tools are often not good for anybody. Designers are much more productive using specialized UI design applications like Sketch, Figma, Adobe XD etc. Who is responsible implementing the design depends on the company/workflow. > XAML is just a tool to a…

Not the biggest fan of XML either. My primary objections against "simple" XML is repeating element names in open and close tags, the noise of , and (in the context of a UI tree) confusion over whether to put element modifiers as XML attributes (strings only) or nested elements (verbose, looks like an object rather than an attribute). And when you bring in namespaces, it gets more verbose and unreadable. I've actually…

To manage mental mapping of what is being drawn, I keep methods that create widget trees short. My rule of thumb is that whole method has to comfortably fit the screen at once. For each section of the main tree I create a static function that returns a branch of the tree. These functions have descriptive names that help you visualize what element each function builds. If a tree inside a function is long, it is broken down in the same way.

There are some fluent extensions (for Xamarin.Forms and probably future MAUI) that help you build UI in declarative fashion with C#. Same extensions could be created for other frameworks.

https://devblogs.microsoft.com/xamarin/c-sharp-markup-for-xa...

https://github.com/VincentH-Net/CSharpForMarkup

For reusable custom widgets that can't be done with a static function, I create new classes with their own widget trees. Try to keep widgets composable and avoid inheritance if possible.

Hot reload is coming in .NET 6, so waiting for rebuild will soon be history.

I have no experience with QML so I can't really comment on that.

Re: Performance Improvements in .NET 6

#219

I'm going to pile in too late and sing the virtues of .NET core or whatever its called now. Deployment of web apps to containers is a breeze, the language is modern feeling. Roslyn is about the most awesome thing I have played with. Razor pages are a breeze compared to the giant piles of dependency hell that client side SPAs or node have become. It feels lean and mean and I can be sitting at a debian box or a windows…

> sing the virtues of .NET core or whatever its called now

I think this is the only criticisms I can level at Microsoft, their branding is just a complete mess!

Core has been dropped from .NET naming but we still have ASP.NET Core MVC (I think?) and we still have EF Core.

"ASP.NET Core MVC" is such a mouthful.

Re: Performance Improvements in .NET 6

#220
post #13

Where should someone start if they wanted to get familiar and proficient with .NET?

For somebody who already knows how to program, and enjoys getting a comprehensive data dump, C# 9.0 In a Nutshell.

c# in Depth (4th edition) is also a good book for data dumping how things work in c#, though I think it only covers through c# 8.
Post reply on HN