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

.NET MAUI: .NET Multi-Platform App UI

github.com

Post reply on HN
Print view View original

221–230 of 260 posts

Re: .NET MAUI: .NET Multi-Platform App UI

#221

Post by Shadonototro »

kaba0 wrote: post #212
Shadonototro wrote: post #105

Earlier quoted context omitted.

C# with MAUI went full OOP Swift with SwiftUI embraced the data oriented way with structs only They both target resource constrained devices, wich will perform better? I can already tell, apps with MAUI will be laggy on most android phones, probably less on iPhones since the hardware/OS is just better, just like with Xamarin today

That’s just absolutely baseless on so many levels

MAUI is open source, check their code

Apple mentioned in their WWDC how they embraced data oriented code for SwiftUI wich gave them great performance by default

Re: .NET MAUI: .NET Multi-Platform App UI

#222

Post by Shadonototro »

metaltyphoon wrote: post #135
Shadonototro wrote: post #105

Earlier quoted context omitted.

C# with MAUI went full OOP Swift with SwiftUI embraced the data oriented way with structs only They both target resource constrained devices, wich will perform better? I can already tell, apps with MAUI will be laggy on most android phones, probably less on iPhones since the hardware/OS is just better, just like with Xamarin today

What? Xamarin apps currently compile to native code, so idk where you are getting this idea from.

It doesn't matter, native code doesn't make your program automatically faster, C# code is hard to aot compile, lot of things happen at runtime and Xamarin uses a lot of that

Also abuse of abstraction layers is what makes your programs slow, most of the time, wich Xamarin and now MAUI does a lot too, that's what you get for abusing OOP

In server they could get away with it thanks to their JIT, since they don't care about cold start

But in AOT scenarios, you depend a lot on the quality of the AOT compiler, how well it does optimizations, and how well your code is written to facilitates good optimizations

Again, MAUI is open source, check their code, you'll understand what i mean by "the code is just slow"

People always forget what they program for, mobile devices are constrained devices with constrained resources

Pumping your desktop PC and claiming your benchmark does well doesn't automatically translate to better perf on mobile

Then people wonder why their app drain the battery so fast, and you get 1 star reviews as a result, people doesn't care, that is why i leave 1 star reviews, most of the time

Re: .NET MAUI: .NET Multi-Platform App UI

#223

Post by zerr »

tonyedgecombe wrote: post #166

Win32->MFC->ATL->WTL->Windows Forms->WPF->WinRT->UWP->WinUI->MAUI More churn, more abstraction, much of it feels unfinished. This is starting to make Electron look attractive.

Many shops working on Windows desktop apps are stuck at WPF due to Windows 7 support.

Re: .NET MAUI: .NET Multi-Platform App UI

#226

Post by nec4b »

andix wrote: post #211
manigandham wrote: post #208

Earlier quoted context omitted.

SPA = single page application. You can make one entirely in Blazor and can host it on any static file host. Are you talking about Javascript specifically?

The difference of Blazor compared to a "classic" SPA (for example React + JSON API) is: Blazor Server: On a broken/poor connection there is no interactivity anymore Blazor WASM (=SPA): Keeps working when connection is lost, but everything is sooo slow classic SPA: Keeps working with lost connection and is fast.

> Blazor WASM (=SPA): Keeps working when connection is lost, but everything is sooo slow

Why should it be slow? Once Blazor WASM is loaded, it doesn't need a connection to the server anymore.

Re: .NET MAUI: .NET Multi-Platform App UI

#227

Post by DonnyV »

flukus wrote: post #160
bob1029 wrote: post #37

The amount of energy Microsoft is pouring into these front-end efforts is pretty incredible. A more recent development that has me very excited is Blazor Desktop: https://medium.com/young-coder/blazor-desktop-the-electron-f... > This leads to the second difference — in a Blazor Desktop app hosted in WebWindow, there’s no built-in web server. Instead, it’s pure .NET all the way down. And while we haven’t seen exactly…

> The amount of energy Microsoft is pouring into these front-end efforts is pretty incredible. After winforms, silverlight, wpf, webforms and WinUI I don't want energy, I want to see them focus for more than 5 minutes. The only stable UI tech from MS with any long term support has been Win32 that came out 25 years ago. I predict blazor will be quietly dropped (they won't actually admit it for 5 years), just like the…

yup, thats why if I need to do a small desktop app I still use WinForms. Its easy to use, mature and performant. Good enough.

Re: .NET MAUI: .NET Multi-Platform App UI

#228

Post by kaba0 »

Shadonototro wrote: post #221
kaba0 wrote: post #212

Earlier quoted context omitted.

That’s just absolutely baseless on so many levels

MAUI is open source, check their code Apple mentioned in their WWDC how they embraced data oriented code for SwiftUI wich gave them great performance by default

And how does OOP result in slower code?

Re: .NET MAUI: .NET Multi-Platform App UI

#229

Post by mikece »

GordonS wrote: post #183
dt3ft wrote: post #180

Earlier quoted context omitted.

So when purchasing Visual Studio subscription in order to write software for windows, you expect nothing to work out of the box? I'd love to see you tackle a WPF monolith within a regulated environment where no 3rd party libs are allowed. It's 2021, we're expected to deliver amazing, feature rich software in very little time, without buying 3rd party libraries. Meanwhile, there's Microsoft, using the funds from our s…

> stuff like Xamarin Forms and abandoning it half-way through Eh? I've worked on projects using Xamarin Forms, and they turned out just fine. Yes, it would be nice if there were a few more controls in the main Xamarin Forms library, but I don't see a problem with the community picking up some of the slack (which they have).

"I've worked on projects using Xamarin Forms, and they turned out just fine."

Same here, but it is my experience with Xamarin that has led me to conclude that it's the wrong choice almost 100% of the time. Sure, it can be made to work but at the end of the day you're coercing C# to do something it was not designed to do. For mobile I am convinced that PWA/hybrid mobile is the correct choice 95% of the time with the remaining 5% being platform native apps written in Android Studio with Kotline or Java (or Xcode with Swift or Obj-C). Anything else is just an exercise in sticking non-round pegs into a round hole.

Re: .NET MAUI: .NET Multi-Platform App UI

#230

Post by JamesSwift »

wsc981 wrote: post #114
JamesSwift wrote: post #56

Earlier quoted context omitted.

Its important to distinguish between Xamarin.Forms and Xamarin.Native (which Forms is built on top of). Xamarin.Native is quite nice and is the best abstraction available today (in my opinion). Xamarin.Forms is indeed not great. It is an OK solution for a subset of problems, but even for those I'm left wondering if the pain is worth it rather than rolling my own native frontends in Xamarin.Native.

Xamarin.Forms might not be great if you want to create a beautiful app that performs very smoothly, but it’s pretty sweet for making multiplatform business apps for use in-house (as in: not sold on app stores) imo.

Right, internal apps are the sort of thing I think fall in the 'subset of problems' its good for, but as soon as you have a design guide to adhere to (i.e. you aren't just shipping the out-of-the-box configurations) its buggy and painful.
Post reply on HN