Live data from Hacker News

.NET MAUI: .NET Multi-Platform App UI

github.com

201–210 of 260 posts

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

#201
post #150

Basically MAUI is the next phase of Xamarin/UWP as that was not fully ported on the UI side in .NET 5 which was the merging of .NET Framework 4.x and .NET Core 3.1. .NET 6 UI is essentially being replaced with this for .NET 6. I use Xamarin/UWP quite a bit for apps that also have to target Surface and it is great, the ability to use Xamarin.Forms and/or use CustomRenderers per platform is nice. This should follow sim…

I think there’s some possibility of slight confusion by mixing Xamarin and UWP together. Xamarin (and thus .NET MAUI, which is cross platform) does not use the same flavor of XAMl as UWP (and thus WinUI, which is Windows only but shares the same XAML as Uno).

Yeah, UWP is a progression on WPF/Silverlight that had its own XAML as part of the platform code/declarative.

Xamarin is from Mono and had its own XAML for Xamarin.Forms that underneath have build in Renderers for platform targets.

Xamarin allows Shared or PCL that can be made for each platform iOS, Android, UWP etc. You can use CustomRenderers for each platform to access the native platforms and write code towards them or use Xamarin.Forms.

Xamarin.Forms is what is being replaced really and the porting to .NET 6 for MAUI, with WinUI for the UWP targets.

Both Xamarin and UWP have differing XAML because they had their own for the platforms they were on, Xamarin from Mono, UWP progression from other Microsoft tech. In a way this version merges that more closely but still can access directly. The default MAUI will use these targets per platform. If you override one you can implement it in direct platform. Xamarin is really just an abstraction around the platforms and some shared controls that have pre-baked renderers that do that for you.

I don't really use XAML much though other than a stub to load Main, everything is done in code usually. Same way I build native apps directly, mostly code except where not possible or the team needs to edit them. For Xamarin I use Shared setup where I can use Xamarin.Forms (and soon MAUI) for ContentPages/Controls but where needed you can still use a CustomRenderer and override a control or access some properties that you want to edit, or create entire controls/sets that aren't shared across all targets as Xamarin creates a baseline between them and renders how each platform does. In those custom scenarios you might use UWP/WinUI if targeting UWP. If targeting iOS/Android it may be UIKit/Foundation or Android the Android libs Views/Graphics/Content etc.

The Shared [1][2] setup and Xamarin.Forms or coming MAUI allow you to quickly get the app running on all platforms and then you can adjust as needed for specifics. Or do the whole thing natively per platform with custom and just manage it from Xamarin. It is flexible and great for prototypes quick and getting those to something that is shippable. The Shared setup this way is similar to the handler approach in MAUI where underneath the shared abstraction controls are converted into platform specific but you can do custom ones to override or combine controls.

[1] https://docs.microsoft.com/en-us/xamarin/cross-platform/app-...

[2] https://docs.microsoft.com/en-us/xamarin/cross-platform/app-...

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

#202
post #152
post #6

This is Xamarin forms with a new name.

And Xamarin forms was never really finished, it is still lacking on every front. Just look at the open issues and feature requests. I would not be surprised if MAUI also gets abandoned halfway through development.

Xamarin.Forms was like an abstraction helper though, underneath all Renderers. You can/could make CustomRenderers for any custom controls or to access any native needs on iOS, Android and UWP directly. That is how most apps ended up.

Xamarin.Forms was great for getting prototypes going to get things running then going in and taking areas you need to customize, or all controls, and making them platform specific to the targets.

You can still have a shared library that does Content/Pages and most of the work shared. I don't know if Xamarin.Forms was ever meant to be a full solution but it is ok for prototypes and enterprise, for actual consumer shipped apps more customization was needed and CustomRenderers.

The Shared [1][2] setup this way is similar to the handler approach in MAUI where underneath the shared abstraction controls are converted into platform specific but you can do custom ones to override or combine controls.

[1] https://docs.microsoft.com/en-us/xamarin/cross-platform/app-...

[2] https://docs.microsoft.com/en-us/xamarin/cross-platform/app-...

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

#203
post #180

Earlier quoted context omitted.

The WPF grids are fine and autocompletion is trivial. Which is the proper way to write frameworks: make it easy to make the bits you don't have. I love that it isn't created like the old RAD frameworks where you are supposed to easily drop a datagrid in, connect to a DB and basically have some Line of Business CRUD on your screen within minutes. The Telerik/Syncfusion et.al. components are massive bloated and geared…

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…

> So when purchasing Visual Studio subscription in order to write software for windows, you expect nothing to work out of the box?

If you mean I expect to compose my own complex controls out of less complex building blocks, then yes that's what I want and expect.

> Meanwhile, there's Microsoft, using the funds from our subscriptions and building stuff like Xamarin Forms and abandoning it half-way through

I agree WPF and others have been backbenched for 10 years. Microsoft panicked and needed a strategy for cloud and mobile, while they weren't exactly being threatened on desktop. So from a business perspective it made perfect sense: leave desktop for 10 years. Now they are slowly coming back to it with .NET 5 which is nice, but it wasn't very pleasant to be a Windows desktop dev between 2010 and 2020.

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

#204
post #2

Any direct experiences using this? I've been looking for a good multiplatform UI for desktop that does Mac/Linux/Windows. Mobile is a nice side benefit. It would be nice to use C# again No, I'm not interested in Electron. Blegh.

Try QtQuick2 if you want to target mobile, too. QtWidgwts for desktop only.

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

#205

Earlier quoted context omitted.

> I have been able to implement things in 4 hours that would easily have taken 4 weeks if I had to argue with other developers about the shape of a JSON blob on the wire. I can’t comment on your specific circumstances because I don’t know the details, but this reads like someone who is drinking the blazer coolaid. It’s a technology like any other, with specific trade offs. If you have a front end team who lacks the b…

The entire point is to avoid javascript as much as possible and to force the few edge cases into an interop shim. We have a very complex Blazor webapp and the JS interop shim is fewer than 200 lines of code. This is 100% of the custom javascript for the entire application. Front and back. We do things like GetClientRect, Get/Set/Delete cookies, keyboard/mouse event subscription, etc. There is little-to-no context swi…

> I rather enjoy being able to set breakpoints in my view templates to confirm the state of affairs in local testing.

That’s a local development environment.

Have you had similar experiences when dealing with deployed applications? How did you do it? It’s rather more difficult when, eg. You can’t have a copy of visual studio there to use on your production deployments.

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

#206
post #187

Earlier quoted context omitted.

The concept is revolutionary, for sure. But for now it doesn't work as well as a classic SPA architecture. The server-side mode works not very well on poor connections (mobile), and the client-side WASM builds are extremely slow. Especially on first load, this takes seconds. Blazor may be well suited for Intranet apps already, where quick&cheap development is very important, and connections are fast and stable. Blazo…

Pages can be server-side rendered and then hydrated after load, in either mode. This makes a dramatic difference in usable latency.

Sure. But it still takes some time until the interactive part works. And it doesn't solve connectivity issues a SPA can easily handle.

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

#207
post #171
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…

While I agree Blazor is great, everytime I use it it feels unfinished. For example binding select inputs to object is not possible while it has been working in other Javascript frameworks for years. Ofcourse you can use workarounds but it always feels like a step back. And for some project that use custom auth it can be difficult to auth both Blazor and Controllers if you need some. But overall it is a great experien…

That's what I always think about MS GUI frameworks.

My rant towards Microsoft:

Get some average students and let them build a real world demo application. Write down all the stupid questions they have and all the problems they struggle with. Consider them as bugs or bad design choices and solve them. Do that before you release stuff.

Microsoft delivers amazing quality in some fields, language design (c# and f#), ASP.NET Core and everything in Micrsoft.Extsions.* is amazing. Also .NET Core was a very successful project (after the hell of PCL and .NET Standard).

But WHY can't you build a proper and usable UI framework?!?!?!!!

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

#208
post #206

Earlier quoted context omitted.

Pages can be server-side rendered and then hydrated after load, in either mode. This makes a dramatic difference in usable latency.

Sure. But it still takes some time until the interactive part works. And it doesn't solve connectivity issues a SPA can easily handle.

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?

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

#209

Earlier quoted context omitted.

The WPF grids are fine and autocompletion is trivial. Which is the proper way to write frameworks: make it easy to make the bits you don't have. I love that it isn't created like the old RAD frameworks where you are supposed to easily drop a datagrid in, connect to a DB and basically have some Line of Business CRUD on your screen within minutes. The Telerik/Syncfusion et.al. components are massive bloated and geared…

WPF DataGrid causes memory leaks - this is still the case in .NET 4.8

Is it still the case in .NET 5 though?

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

#210
post #73

Earlier quoted context omitted.

Xaml hot reload only works on about half of our views at work, and even then it tends to break itself. I've tried net framework, net core, and net 5. The newer targets break less often but we still can't ship net 5 thanks to Windows 7 extended support contracts from Microsoft. It doesn't even compare to blazors implementation. And c# hot reload breaks frequently around asyncs and lambdas.

> The newer targets break less often but we still can't ship net 5 thanks to Windows 7 extended support contracts from Microsoft You make it sound like it's Microsoft's fault your customers won't move off of Windows 7.

He has a point, for example now they've finally stopped supporting IE11 you can legitimately say to customers that supporting IE11 is no longer possible because it's a security hole.

Extended support by MS for Windows 7 means the only reason you're not supporting it yourself is your lack of motivation, and so to your customers (and your own upper management), for a big contract that's not going to wash.

You might even find that their contract even says something to that effect.

Post reply on HN