Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Performance Improvements in .NET 6

devblogs.microsoft.com

Post reply on HN
Print view View original

131–140 of 256 posts

Re: Performance Improvements in .NET 6

#131

Post by mhoad »

tomnipotent wrote: post #56
addicted wrote: post #43

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.

Is there a UI story that doesn't suck?

I feel like right now flutter is about 1/10th the level of popularity it will eventually reach. It has a great story for UI from multiple angles (cross platform, developer experience, tooling etc).

It’s still very young v2 only came out a couple of months ago so it’s not entirely without issues at the moment but there are a LOT of apps that I think could easily use Flutter in production across all platforms today and that story is only getting better.

Re: Performance Improvements in .NET 6

#132

Post by pjmlp »

lbriner wrote: post #121
zigzag312 wrote: post #117

Earlier quoted context omitted.

All upcoming UI frameworks by MS are still hung up on XAML. I get that their existing userbase is heavily invested in XAML, but in my experience XAML doesn't add much value, just unnecessarily layer of complexity, that lacks expressiveness of a programming language and makes interoperability between UI and code more convoluted. There is some "experimental" support for code based UI composition in MAUI, but since XAML…

I would question how invested the existing customers are in XAML. I have worked at about 6 companies that all use .Net exclusively and I don't think we used XAML once except for maybe an experiment or PoC. I think the XAML stuff relates more to trying to make things move between devices more easily by using generic ideas like stretching, grid layouts, flows etc. I guess MS are still holding onto the write-once use an…

So they write their WPF applications in pure C# and VB.NET code?

Re: Performance Improvements in .NET 6

#133

Post by pjmlp »

Xevi wrote: post #130
tester34 wrote: post #129

Earlier quoted context omitted.

What's wrong with XAML and what could have replace it? Maybe HTML?

I haven't used it that much, but from my experience it was incredibly difficult/verbose to create any custom designs, compared to HTML/CSS. It put me off so much that I just picked another language to develop my applications in.

Coming from Windows development since Windows 3.0, I have the exact opposite opinion.

With XAML I can make my ideas fly, with Web, despite doing Web since 1998, I rather let our designer do their magic with HTML, CSS, JavaScript, turning into animated drop downs.

Re: Performance Improvements in .NET 6

#134

Post by pjmlp »

lloydatkinson wrote: post #127
pjmlp wrote: post #95

Earlier quoted context omitted.

Maui is built on top of UWP, in what concerns Windows backend. Have to agree with the desktop development chaos, look like not wanting to take an hard decision. Forms and WPF continue, because they are the golden eggs, the ones that most .NET desktop devs actually care about. WinUI looks like last attempt to rescue UWP, while at the same time in typical Microsoft fashion ignoring the tooling issues surrounding .NET N…

> Maui is built on top of UWP, in what concerns Windows backend. No it is not, how is that going to work on Mac? It is it's own thing, and on Windows it will use WinUI not UWP.

Learn before commenting.

WinUI is UWP stack, that is what Reunion is all about, merging both worlds with WinUI on top.

Plenty of blog posts where to find such information.

Re: Performance Improvements in .NET 6

#135

Post by ygra »

foepys wrote: 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…

> Not to mention that porting WinForms from .NET Framework to .NET 6 requires a rewrite for anything more complex than a Hello World.

We sell a fairly complex custom control, both for Windows Forms and WPF. There were zero changes necessary for the migration to .NET Core 3 back then. We still build both .NET Framework and .NET Core assemblies from exactly the same source.

Depending on how many 3rd-party dependencies are used and what other weirdnesses one does in code there may well be projects that are impossible or really hard to convert. But overall my experience was that for a lot of applications there are few, if any, changes necessary.

Re: Performance Improvements in .NET 6

#136

Post by Someone »

foepys wrote: post #45
throwaway13337 wrote: post #10

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.

Visual C++ had that years ago (2005, reading https://blog.codinghorror.com/revisiting-edit-and-continue/)

IIRC, that required a debug build that didn’t run very fast and was a bit fickle. Managed languages maki it a lot easier to implement this kind of features.

Re: Performance Improvements in .NET 6

#137

Post by pjmlp »

dgellow wrote: post #88
foepys wrote: 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…

What are you talking about? WPF is still supported and a viable way to implement UI components. Same for WinForms. UWP never replaced them. What they are doing with WinApp SDK and WinUI is to extract features that were packaged with UWP to make them available to any type of Windows application. Xamarin is also still a thing, MAUI will be a thing in the future, Uno is another option, Avalon too. There is a lot of opti…

While true in spirit, the GitHub and developer voice tickets kind of show the actual state of affairs, which kind of saddens me.

It feels like desktop teams are running into all possible solutions to see what sticks, instead of fixing what we had.

Re: Performance Improvements in .NET 6

#138

Post by lmm »

GiorgioG wrote: post #32
Rapzid wrote: post #17

Earlier quoted context omitted.

A lot of the library ecosystem still feels dominated by companies who make their money selling library code. If more successful, open-source friendly companies adopt .Net to create higher-level products and services one would hope that would help contribute to a more well maintained and more friendly licensed ecosystem. My sense is that things are improving though.

I'm not entirely sure where you get that 'feeling' from if you work on anything .NET related. If you're on the outside looking in, there's 270,000 packages listed on NuGet.org

That's progress, but it's also about the same number as maven central had in 2010.

Re: Performance Improvements in .NET 6

#139

Post by pjmlp »

jrsj wrote: post #107
foepys wrote: 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…

As far as UI in .NET in general goes they seem to be throwing stuff at the wall to see what sticks, and no one project seems to have a lot of resources dedicated to it. I imagine this is because it’s simply not a priority for the .NET team. Maybe it’s undervalued a bit, or maybe it’s making the best with the resources they have.

As I mentioned in another comments, I feel that they disbanded everyone as of Windows 8 and UWP, as many businesses did not follow along, they were forced to reboot Forms and WPF teams.

Then you now have Blazor trying to be everywhere, with Xamarin being redone as MAUI (you are expected to rewrite your Xamarin code).

So not so rosy for the time being.

Re: Performance Improvements in .NET 6

#140

Post by DiabloD3 »

zigzag312 wrote: post #117
smackeyacky wrote: post #94

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…

All upcoming UI frameworks by MS are still hung up on XAML. I get that their existing userbase is heavily invested in XAML, but in my experience XAML doesn't add much value, just unnecessarily layer of complexity, that lacks expressiveness of a programming language and makes interoperability between UI and code more convoluted. There is some "experimental" support for code based UI composition in MAUI, but since XAML…

You have never been required to use XAML, however. XAML is just a tool to allow you to describe UI API calls using XML in a way that flows well for both humans and external tooling. If you don't like XAML, just call the same exact API with C#.

I don't even understand why you say "hung up on", XAML is probably the only compiles-to-code UI API I've ever used that actually does what it says it does; I've used similar tools for other UI toolkits (Glade comes to mind), and they're trainwrecks, and I'd rather just use the API straight.

UI development tools aren't for programmers, they're for UI designers: UI designers are generally are bad programmers but good designers, but need to program somehow as part of their job, and UI design tools allow them to be part of the team without having to feel like they're second-class citizens.

You know what happens when we don't have working UI toolsets? UI designers do insane stuff like slap together some HTML, CSS, and JS, and don't care that the usability of that from either the end-user perspective or the programming perspective is absolutely awful.

Would you rather use Electron or would you rather use XAML? At least with XAML, it works, and when it doesn't work, it can be made to work. Electron is eternally unfixable.

Post reply on HN